Repository navigation
Conversation
Follow one ClusterExtension through standard OLM installation, the OLM upgrade, and a subsequent bundle update. Separate scenarios with shared once-only installers previously updated a new extension created after the upgrade and missed failures migrating the original extension. Record live resource identities and assert the experimental CE to COD to COS ownership handoff, migration revision, normal rollout revisions, and current-generation status. Retain Helm-backed standard upgrade coverage, refresh runtime feature gates, and reject stale leader leases. Use small generated bundles and leave migration runtime changes for a separate fix. The experimental upgrade cases should expose the existing ownership conflict until that fix lands. Co-authored-by: Codex <noreply@openai.com> Signed-off-by: Francesco Giudici <fgiudici@redhat.com>
openshift-ci
Bot
added
the
do-not-merge/work-in-progress
|
[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 |
✅ Deploy Preview for olmv1 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: true
|
fgiudici
added
the
do-not-merge/hold
4 tasks
This branch has not been deployed
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
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.
Description
The upgrade suite previously upgraded OLM only once across two scenarios.
The catalog scenario created the extension that actually crossed the upgrade,
but never checked its migration. The extension scenario created a different
extension after experimental OLM was already running. Green upgrade jobs
therefore did not demonstrate migration of a pre-existing extension.
Use one scenario that installs generated bundle 1.0.0 on standard OLM,
upgrades OLM, verifies the same extension and managed object identities,
then updates that extension to 1.0.1. For experimental destinations, require
CE -> COD -> COS controller ownership, completed archived migration revision
1/None, ready revision 2/Prevent, and revision 3 after the bundle update.
Require current-generation status and preserve COD/earlier revision UIDs.
Standard destinations continue to validate Helm-backed installs and updates.
Refresh deployed feature gates and component namespaces after installation
and upgrade, initialize the runner's logging/cleanup, and require leader
leases to point to the current deployment revision. The deterministic small
fixtures use default etcd limits and strict CRD safety.
Test-only part of OPRUN-4814. Hold pending the separate migration ownership
fix: these assertions expect migration to succeed and should fail on the
unchanged runtime. Runtime fixes and the pre-existing oversized inline
migration storage limitation are outside this PR.
Validation uses unchanged runtime source at 98bf7e3, local images built at
b394d9ad, and Kubernetes 1.37.0 in separately named disposable Kind clusters.
steps, including the same-CE update to 1.0.1 (f4b4d0f).
the new migration assertion: 16 steps passed, 1 failed, 13 skipped
(05b5a48b; experimental assertions unchanged in f4b4d0f).
migration assertion: 16 steps passed, 1 failed, 13 skipped (05b5a48b).
rev1/None still controlled by the CE, COD
Progressing=False/OwnerConflictand
Available=False/NoActiveRevision, and no revision 2. All 10 fixtureobjects are ready; etcd retains its normal 1.5 MiB request limit. No owner
patches, CRD safety overrides, or runtime modifications were used.
make lint,make verify, and the focused steps/catalog tests: passed onf4b4d0f. The Helm decoder regression test confirms stored bundle labels are
preserved.
make test-unitpassed before the test-helper-only refinements.The failing experimental paths stop before the bundle-update steps. Those
steps and the successful rev2/rev3 ownership assertions must also pass atop
the separate runtime fix before this test PR is merged.
Reviewer Checklist