-
Notifications
You must be signed in to change notification settings - Fork 144
[kustomize_deploy] Fix InstallPlan approval to respect deployment version #3591
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…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]>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Build failed (check pipeline). Post https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/6b4e7112571942e0b3a8241a7614a78a ✔️ openstack-k8s-operators-content-provider SUCCESS in 2h 26m 57s |
|
note this requires to pass the new |
|
recheck |
|
@sathlan please have a look at this change. its related to the FR2->FR4 update testing |
abays
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
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:
Seen when the installplans had this ordering:
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:
With the fix:
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