Skip to content

Conversation

@stuggi
Copy link
Contributor

@stuggi stuggi commented Jan 8, 2026

Bug: When deploying with cifmw_ci_gen_kustomize_values_deployment_version set and installplan_approval=Manual, the install_plan.yml task would approve ALL unapproved InstallPlans, not just the one matching the specified version. This can cause the base version and any newer versions in the bundle to be approved, preventing proper update testing scenarios.

For example, when deploying v1.0.7 to test an update to v1.0.18:

  • Expected: Only v1.0.7 InstallPlan approved, v1.0.18 left for manual approval
  • Actual: Both v1.0.7 and v1.0.18 InstallPlans were approved after running deploy-architecture.sh

Seen when the installplans had this ordering:

$ oc get installplan -n openstack-operators
NAME            CSV                          APPROVAL   APPROVED
install-6r9p6   openstack-operator.v1.0.18   Manual     true
install-hqdf7   openstack-operator.v1.0.7    Manual     true

Root cause: The task selected the first unapproved InstallPlan without checking if it matched the requested CSV version.

Fix: Added version filtering using spec.clusterServiceVersionNames when cifmw_ci_gen_kustomize_values_deployment_version is defined. The task now:

  1. Waits for an InstallPlan matching the specific CSV version
  2. Selects only the InstallPlan for that version
  3. Displays which CSV version is being approved for visibility

With the fix:

$  oc get installplan -n openstack-operators
NAME            CSV                          APPROVAL   APPROVED
install-dx7b5   openstack-operator.v1.0.18   Manual     false
install-h758h   openstack-operator.v1.0.7    Manual     true

Backward compatibility: When cifmw_ci_gen_kustomize_values_deployment_version is not defined, the original behavior (approve first unapproved InstallPlan) is maintained.

Related: OSPRH-23688

…sion

Bug: When deploying with cifmw_ci_gen_kustomize_values_deployment_version
set and installplan_approval=Manual, the install_plan.yml task would
approve ALL unapproved InstallPlans, not just the one matching the
specified version. This can cause the base version and any newer
versions in the bundle to be approved, preventing proper update testing
scenarios.

For example, when deploying v1.0.7 to test an update to v1.0.18:
- Expected: Only v1.0.7 InstallPlan approved, v1.0.18 left for manual approval
- Actual: Both v1.0.7 and v1.0.18 InstallPlans were approved after
  running deploy-architecture.sh

Seen when the installplans had this ordering:
$ oc get installplan -n openstack-operators
NAME            CSV                          APPROVAL   APPROVED
install-6r9p6   openstack-operator.v1.0.18   Manual     true
install-hqdf7   openstack-operator.v1.0.7    Manual     true

Root cause: The task selected the first unapproved InstallPlan without
checking if it matched the requested CSV version.

Fix: Added version filtering using spec.clusterServiceVersionNames when
cifmw_ci_gen_kustomize_values_deployment_version is defined. The task now:
1. Waits for an InstallPlan matching the specific CSV version
2. Selects only the InstallPlan for that version
3. Displays which CSV version is being approved for visibility

With the fix:
$  oc get installplan -n openstack-operators
NAME            CSV                          APPROVAL   APPROVED
install-dx7b5   openstack-operator.v1.0.18   Manual     false
install-h758h   openstack-operator.v1.0.7    Manual     true

Backward compatibility: When cifmw_ci_gen_kustomize_values_deployment_version
is not defined, the original behavior (approve first unapproved InstallPlan)
is maintained.

Related: OSPRH-23688

Co-Authored-By: Claude Sonnet 4.5 <[email protected]>
Signed-off-by: Martin Schuppert <[email protected]>
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jan 8, 2026

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign valkyrie00 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@stuggi stuggi requested review from abays, dprince and sathlan January 8, 2026 16:24
@softwarefactory-project-zuul
Copy link

Build failed (check pipeline). Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.

https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/6b4e7112571942e0b3a8241a7614a78a

✔️ openstack-k8s-operators-content-provider SUCCESS in 2h 26m 57s
✔️ podified-multinode-edpm-deployment-crc SUCCESS in 1h 28m 13s
cifmw-crc-podified-edpm-baremetal RETRY_LIMIT in 12m 57s
✔️ cifmw-crc-podified-edpm-baremetal-minor-update SUCCESS in 2h 09m 43s
cifmw-pod-zuul-files FAILURE in 4m 51s
✔️ noop SUCCESS in 0s
cifmw-pod-ansible-test FAILURE in 5m 19s
cifmw-pod-pre-commit FAILURE in 6m 28s
✔️ cifmw-architecture-validate-hci SUCCESS in 5m 37s
✔️ cifmw-molecule-kustomize_deploy SUCCESS in 5m 18s

@stuggi
Copy link
Contributor Author

stuggi commented Jan 9, 2026

note this requires to pass the new cifmw_ci_gen_kustomize_values_deployment_version to the update task run, which I think is correct, especially of we have multiple available to update to.

@stuggi
Copy link
Contributor Author

stuggi commented Jan 9, 2026

recheck

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant