Summary
test_build_bundle fails while building a bundle for a CMR integration test plan involving nginx-ingress-integrator as a neighbor charm. The bundle builder now reports nginx-ingress-integrator as supporting only the kubernetes platform, but the test/bundle spec still requests it be resolved on the machine platform, causing an UncompletableBundleError.
bundle_builder_x.bundle_builder.UncompletableBundleError: Could not build a complete valid bundle:
Cannot resolve requested charm release for neighbor (nginx-ingress-integrator, model
charmqa-35126254128-03607688/charmqa-35126254128-25303779): Charm 'nginx-ingress-integrator'
supports platform(s) ['kubernetes'], but platform 'machine' was requested
Environment / Reproduction
- Test Observer artefact:
spark-history-server-k8s (id 409818), version 119
- Test execution: 685453
- Test plan:
integration/nginx-ingress-integrator:ingress/ingress/spark-history-server-k8s:ingress
- Environment:
juju:4/stable ubuntu:22.04 cmr/kubernetes/openstack
- CI run: https://github.com/canonical/charm-integration-testing/actions/runs/35126254128
- Reproduced consistently across at least 2 consecutive executions (685447, 685453)
- Same failure class (charm platform reclassified as
kubernetes, but machine requested) also observed independently for istio-pilot as a neighbor in another test run.
Relationship to #956
This looks like a follow-on/regression from #956 ("bundle_builder_x misclassifies assumes:[k8s-api] charms without containers as machine-only (nginx-ingress-integrator)"), rather than a recurrence of the same bug. The error signature and direction of the mismatch are the opposite of #956:
Filing as a new issue since the code path/error differs from #956, but linking here since the fix for #956 (SQT-1216) likely needs a companion update to whatever test-plan/bundle data hardcodes the neighbor's platform.
Suggested next step
Audit test-plan/bundle definitions (and any cached charm-platform data) that still hardcode nginx-ingress-integrator / istio-pilot as machine platform, and update them to kubernetes now that the classifier correctly reports it — or make bundle_builder_x tolerate/auto-correct a stale machine request when the charm's live classification is kubernetes.
Summary
test_build_bundlefails while building a bundle for a CMR integration test plan involvingnginx-ingress-integratoras a neighbor charm. The bundle builder now reportsnginx-ingress-integratoras supporting only thekubernetesplatform, but the test/bundle spec still requests it be resolved on themachineplatform, causing anUncompletableBundleError.Environment / Reproduction
spark-history-server-k8s(id 409818), version 119integration/nginx-ingress-integrator:ingress/ingress/spark-history-server-k8s:ingressjuju:4/stable ubuntu:22.04 cmr/kubernetes/openstackkubernetes, butmachinerequested) also observed independently foristio-pilotas a neighbor in another test run.Relationship to #956
This looks like a follow-on/regression from #956 ("bundle_builder_x misclassifies assumes:[k8s-api] charms without containers as machine-only (nginx-ingress-integrator)"), rather than a recurrence of the same bug. The error signature and direction of the mismatch are the opposite of #956:
nginx-ingress-integratorwas misclassified asmachine-only, and routed to an LXD model that couldn't satisfyassumes: [k8s-api].nginx-ingress-integrator(and similarlyistio-pilot) is now correctly classified askubernetes-only, but some other component (test-plan/bundle spec data, possibly the same doc SQT-1178: bundle_builder_x misclassifies assumes:[k8s-api] charms without containers as machine-only (nginx-ingress-integrator) #956 flagged as stale: "the test plan doc had (correctly, given the current framework behavior) recorded nginx-ingress-integrator as platforms: ['machine']") still explicitly requestsmachinefor it, producing a new mismatch.Filing as a new issue since the code path/error differs from #956, but linking here since the fix for #956 (SQT-1216) likely needs a companion update to whatever test-plan/bundle data hardcodes the neighbor's platform.
Suggested next step
Audit test-plan/bundle definitions (and any cached charm-platform data) that still hardcode
nginx-ingress-integrator/istio-pilotasmachineplatform, and update them tokubernetesnow that the classifier correctly reports it — or make bundle_builder_x tolerate/auto-correct a stalemachinerequest when the charm's live classification iskubernetes.