[update] Save and restore customContainerImages around targetVersion patch#1139
Closed
rebtoor wants to merge 1 commit into
Closed
[update] Save and restore customContainerImages around targetVersion patch#1139rebtoor wants to merge 1 commit into
customContainerImages around targetVersion patch#1139rebtoor wants to merge 1 commit into
Conversation
Contributor
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: rebtoor 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 |
rebtoor
changed the title
customContainerImages webhook validation in CI
rebtoor
changed the title
customContainerImages when patching targetVersion
…on` patch Starting with openstack-operator FR4 (openstack-k8s-operators/openstack-operator#1569, merged Oct 2025), the `OpenStackVersion` admission webhook rejects `targetVersion` changes when `spec.customContainerImages` are identical to those tracked for the previously deployed version. In CI the same delorean hash is used for both the greenfield deployment and the simulated version bump, so `customContainerImages` are legitimately identical. Simply clearing them is not safe because the operator falls back to CSV defaults which may point to an inaccessible upstream registry (`quay.io`), while the custom images point to the internal mirror (`images.paas.redhat.com`). Work around this by saving `customContainerImages`, nulling them in the same merge patch that sets `targetVersion` (so the webhook's `hasAnyCustomImage` check returns false and skips validation), then immediately restoring them before the operator reconciles. This preserves the correct internal-mirror image references while bypassing the webhook. Assisted-by: Cursor (claude-4.6-opus-high) Signed-off-by: Roberto Alfieri <ralfieri@redhat.com>
rebtoor
changed the title
customContainerImages when patching targetVersioncustomContainerImages around targetVersion patch
Contributor
|
@rebtoor but we shouldn't go different process then what we document, we don't allow update without customcontainer images for reasons openstack-k8s-operators/openstack-operator#1569 , so i think we should avoid any hack in CI too |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Starting with openstack-operator FR4
(openstack-k8s-operators/openstack-operator#1569, merged Oct 2025),
the
OpenStackVersionadmission webhook rejectstargetVersionchanges when
spec.customContainerImagesare identical to thosetracked for the previously deployed version.
In CI the same delorean hash is used for both the greenfield
deployment and the simulated version bump, so
customContainerImagesare legitimately identical. Simply clearing them is not safe
because the operator falls back to CSV defaults which may point to
an inaccessible upstream registry (
quay.io), while the customimages point to the internal mirror (
images.paas.redhat.com).Work around this by saving
customContainerImages, nulling themin the same merge patch that sets
targetVersion(so the webhook'shasAnyCustomImagecheck returns false and skips validation), thenimmediately restoring them before the operator reconciles. This
preserves the correct internal-mirror image references while
bypassing the webhook.
Assisted-by: Cursor (claude-4.6-opus-high)