INTEROP-9358: Fix operator channel and preflight compatibility for OPP upgrade configs - #82372
Conversation
…P upgrade configs - Fix Quay channel stable-3.14 to stable-3.17 in 4.22 upgrade config (stable-3.14 is outside Red Hat tested integrations for OCP 4.21) - Add OPP_COMPAT entry for OCP 5.0 (key "0", ACM 2.17 + Quay 3.17)
- Keep quay-operator with stable-3.17 channel (present in v5.0 catalog) - Add missing interop-opp-backup and interop-opp-preflight steps - Source proxy-conf.sh for proxy environment support - Fix CSV matching from substring to prefix (index == 1)
openshift-ci-robot
added
the
jira/valid-reference
|
@amp-rh: This pull request references INTEROP-9358 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "5.0.0" version, but no target version was set. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository YAML (base), Central YAML (inherited) Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughThe OPP upgrade workflow updates Quay Operator channels, adds backup and preflight steps, expands compatibility checks to OCP major.minor versions, loads shared proxy settings, and tightens CSV and namespace matching. ChangesOPP upgrade workflow
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: Important Pre-merge checks failedPlease resolve all errors before merging. Addressing warnings is optional. ❌ Failed checks (1 error)
✅ Passed checks (14 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@ci-operator/step-registry/interop/opp/preflight/interop-opp-preflight-commands.sh`:
- Line 76: Update check_opp_compatibility so an unparseable CSV version
increments failed and causes the compatibility check to fail, rather than only
logging a warning and continuing. Preserve the existing compatibility validation
for parseable versions and ensure the active OPP_COMPAT["0"] entry cannot report
success when its versions are unparseable.
- Line 76: Update the OPP_COMPAT entry used by the preflight compatibility check
so its key conveys the target OCP 5.0 major version rather than only minor
version 0. Ensure the helper’s logs and report details identify OCP 5.0
correctly while preserving the existing compatibility image mappings.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: d2606581-fbb1-4729-b9f9-8abbc4bae429
📒 Files selected for processing (2)
ci-operator/config/stolostron/policy-collection/stolostron-policy-collection-main__ocp4.22-upgrade.yamlci-operator/step-registry/interop/opp/preflight/interop-opp-preflight-commands.sh
Address CodeRabbit review: - Increment failed counter for unparseable CSV versions so the compatibility check fails instead of silently passing - Extract target major version and pass to check functions so OCP 5.0 logs correctly instead of showing "OCP 4.0"
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
ci-operator/step-registry/interop/opp/preflight/interop-opp-preflight-commands.sh (1)
105-145: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winUse the target major version in every API-deprecation diagnostic.
For OCP 5.0, the no-find message reports
5.0, but the flagged-entry details still say APIs were removed in4.${minor}, and the JSON report does not include the target version in its success details. This leaves console output and the structured report inconsistent.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@ci-operator/step-registry/interop/opp/preflight/interop-opp-preflight-commands.sh` around lines 105 - 145, Update the API-deprecation diagnostics in the surrounding scan function to use target_major consistently: flagged entries must report removal in ${target_major}.${minor}, and the successful append_check details must include the target version alongside the no-find message. Preserve the existing warning behavior and detection logic.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@ci-operator/step-registry/interop/opp/preflight/interop-opp-preflight-commands.sh`:
- Around line 155-156: Update the compatibility lookup in the preflight command
flow to key OPP_COMPAT by the full target major/minor version rather than
target_minor alone. Construct and use the same major/minor key for compat_spec
and update all OPP_COMPAT matrix declarations consistently, ensuring OCP 5.0
entries do not apply to OCP 4.0.
In
`@ci-operator/step-registry/interop/opp/upgrade/interop-opp-upgrade-commands.sh`:
- Line 366: Update the namespace discovery logic near the CSV health validation
to select CSVs whose metadata.name starts with the operator value, matching the
startswith($op) behavior in the phase query. Replace the contains-based
filtering and collect namespaces only from this prefix-matched CSV set.
---
Outside diff comments:
In
`@ci-operator/step-registry/interop/opp/preflight/interop-opp-preflight-commands.sh`:
- Around line 105-145: Update the API-deprecation diagnostics in the surrounding
scan function to use target_major consistently: flagged entries must report
removal in ${target_major}.${minor}, and the successful append_check details
must include the target version alongside the no-find message. Preserve the
existing warning behavior and detection logic.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: ca1190b8-4cbc-4ce8-a876-aa8ee0e31616
📒 Files selected for processing (3)
ci-operator/config/stolostron/policy-collection/stolostron-policy-collection-main__ocp5.0-upgrade.yamlci-operator/step-registry/interop/opp/preflight/interop-opp-preflight-commands.shci-operator/step-registry/interop/opp/upgrade/interop-opp-upgrade-commands.sh
- OPP_COMPAT keys now use "major.minor" format (e.g., "4.22", "5.0") instead of minor-only, eliminating ambiguity for OCP 5.x - Include target version in API deprecation pass message - Fix flagged API message to use target_major instead of hardcoded "4" - Fix contains -> startswith in upgrade script namespace lookup to prevent false substring matches (consistent with line 366)
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
ci-operator/step-registry/interop/opp/preflight/interop-opp-preflight-commands.sh (1)
131-144: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winDo not let the OCP 5.0 API scan falsely pass.
The scan still selects removals using
minor <= target_minor. For target5.0,target_minoris0, so prior OCP 4.x entries are skipped and the script can record a successful scan even when deprecated APIs are present. Compare full major.minor releases, or explicitly include all historical 4.x entries whentarget_major > 4, before emitting the pass result.Based on the supplied OCP 5.0 preflight workflow and target-version handling in this file.
Suggested fix
- if (( minor <= target_minor )); then + if (( target_major > 4 || minor <= target_minor )); then🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@ci-operator/step-registry/interop/opp/preflight/interop-opp-preflight-commands.sh` around lines 131 - 144, Update the API-removal selection logic in the preflight scan to compare complete major.minor release values rather than only minor values, ensuring target 5.0 includes applicable historical OCP 4.x removals. Preserve the existing found_count handling and only emit the pass result after all relevant deprecated APIs have been evaluated.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In
`@ci-operator/step-registry/interop/opp/preflight/interop-opp-preflight-commands.sh`:
- Around line 131-144: Update the API-removal selection logic in the preflight
scan to compare complete major.minor release values rather than only minor
values, ensuring target 5.0 includes applicable historical OCP 4.x removals.
Preserve the existing found_count handling and only emit the pass result after
all relevant deprecated APIs have been evaluated.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: 81a6d0d2-cf75-41df-96aa-4d345eabe3e3
📒 Files selected for processing (2)
ci-operator/step-registry/interop/opp/preflight/interop-opp-preflight-commands.shci-operator/step-registry/interop/opp/upgrade/interop-opp-upgrade-commands.sh
🚧 Files skipped from review as they are similar to previous changes (1)
- ci-operator/step-registry/interop/opp/upgrade/interop-opp-upgrade-commands.sh
|
/pj-rehearse periodic-ci-stolostron-policy-collection-main-ocp4.22-upgrade-interop-opp-upgrade-aws |
|
@amp-rh: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
@amp-rh: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
/pj-rehearse ack |
Rehearsal Failure AnalysisThe failing rehearsal ( What failedThe Why this is NOT caused by this PRThe only change to the OCP 4.22 config is bumping Corroborating evidenceThe base periodic job has never succeeded — it has a 0% pass rate across all historical runs (2 runs, both failed). Those runs failed even earlier with a CVO/installer version mismatch during bootstrap. This rehearsal actually got further than the periodic job normally does. RecommendationThis rehearsal failure is safe to acknowledge. Consider running: cc @yiraeChristineKim for approval (config OWNERS), @jan-law @dhaiducek for review/lgtm |
|
@amp-rh: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
openshift-merge-bot
Bot
added
the
rehearsals-ack
|
@redhat-chai-bot: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
Friendly bump on this PR — it's been open for review for about a day now. 🙂 Quick recap:
What's still needed to merge:
@yiraeChristineKim @jan-law @dhaiducek @shakyav — would any of you be able to take a look when you get a chance? The changes are straightforward (Quay channel bump for 4.22 + OCP 5.0 compatibility matrix entry). Thanks! |
|
/approve |
openshift-ci
Bot
added
the
approved
For OCP 5.0 (target_minor=0), the scan loop skipped all entries since no minor version is <= 0. Include all historical 4.x API removals when the target major version exceeds 4.
|
[REHEARSALNOTIFIER]
Interacting with pj-rehearseComment: Once you are satisfied with the results of the rehearsals, comment: |
openshift-merge-bot
Bot
removed
the
rehearsals-ack
|
/pj-rehearse ack |
|
@amp-rh: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
openshift-merge-bot
Bot
added
the
rehearsals-ack
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: amp-rh, chaclark1974, dhaiducek The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
rhacs-operator reappeared in the OCP 5.0 redhat-operators catalog (July 31 sync, stable channel head v4.11.2). It was removed in openshift#82372 because the catalog was empty at the time. Includes operator_group field to ensure the install-operators step creates the required OperatorGroup in the rhacs-operator namespace. odf-operator remains excluded until it is published to the 5.0 catalog (tracked by RHSTOR-8660, expected ~Nov 2026).
![openshift-prow[bot]](https://github.githubassets.com/images/gravatars/gravatar-user-420.png){kind=avatar}
…P upgrade configs (openshift#82372) * INTEROP-9358: Fix operator channel and preflight compatibility for OPP upgrade configs - Fix Quay channel stable-3.14 to stable-3.17 in 4.22 upgrade config (stable-3.14 is outside Red Hat tested integrations for OCP 4.21) - Add OPP_COMPAT entry for OCP 5.0 (key "0", ACM 2.17 + Quay 3.17) * INTEROP-9337: Fix 5.0 upgrade config and harden upgrade script - Keep quay-operator with stable-3.17 channel (present in v5.0 catalog) - Add missing interop-opp-backup and interop-opp-preflight steps - Source proxy-conf.sh for proxy environment support - Fix CSV matching from substring to prefix (index == 1) * Fix unparseable version gate and version display in preflight Address CodeRabbit review: - Increment failed counter for unparseable CSV versions so the compatibility check fails instead of silently passing - Extract target major version and pass to check functions so OCP 5.0 logs correctly instead of showing "OCP 4.0" * Use major.minor compat keys and fix contains/startswith inconsistency - OPP_COMPAT keys now use "major.minor" format (e.g., "4.22", "5.0") instead of minor-only, eliminating ambiguity for OCP 5.x - Include target version in API deprecation pass message - Fix flagged API message to use target_major instead of hardcoded "4" - Fix contains -> startswith in upgrade script namespace lookup to prevent false substring matches (consistent with line 366) * Fix API deprecation scan for OCP 5.0 targets For OCP 5.0 (target_minor=0), the scan loop skipped all entries since no minor version is <= 0. Include all historical 4.x API removals when the target major version exceeds 4.
…P upgrade configs (openshift#82372) * INTEROP-9358: Fix operator channel and preflight compatibility for OPP upgrade configs - Fix Quay channel stable-3.14 to stable-3.17 in 4.22 upgrade config (stable-3.14 is outside Red Hat tested integrations for OCP 4.21) - Add OPP_COMPAT entry for OCP 5.0 (key "0", ACM 2.17 + Quay 3.17) * INTEROP-9337: Fix 5.0 upgrade config and harden upgrade script - Keep quay-operator with stable-3.17 channel (present in v5.0 catalog) - Add missing interop-opp-backup and interop-opp-preflight steps - Source proxy-conf.sh for proxy environment support - Fix CSV matching from substring to prefix (index == 1) * Fix unparseable version gate and version display in preflight Address CodeRabbit review: - Increment failed counter for unparseable CSV versions so the compatibility check fails instead of silently passing - Extract target major version and pass to check functions so OCP 5.0 logs correctly instead of showing "OCP 4.0" * Use major.minor compat keys and fix contains/startswith inconsistency - OPP_COMPAT keys now use "major.minor" format (e.g., "4.22", "5.0") instead of minor-only, eliminating ambiguity for OCP 5.x - Include target version in API deprecation pass message - Fix flagged API message to use target_major instead of hardcoded "4" - Fix contains -> startswith in upgrade script namespace lookup to prevent false substring matches (consistent with line 366) * Fix API deprecation scan for OCP 5.0 targets For OCP 5.0 (target_minor=0), the scan loop skipped all entries since no minor version is <= 0. Include all historical 4.x API removals when the target major version exceeds 4.
5 participants
Summary
Fix Quay operator channel in the 4.22 upgrade config and add OCP 5.0 entry to the OPP compatibility matrix.
What it does:
• Fixes the Quay operator channel in the 4.22 upgrade config (stable-3.14 to stable-3.17); 3.14 is outside tested integrations for OCP 4.21
• Adds an OCP 5.0 entry to the OPP compatibility matrix (only ACM 2.17+ and Quay 3.17+ are present in the v5.0 catalog)
• Improves preflight version parsing and upgrade step health validation
Changes
Quay channel fix (4.22 upgrade config): Change
stable-3.14tostable-3.17. Quay 3.14 is outside Red Hat tested integrations for OCP 4.21 (the source version). Verified against Red Hat operator catalog index.OPP_COMPAT entry for OCP 5.0: Add
OPP_COMPAT["0"]with ACM 2.17 and Quay 3.17 minimums. Only these two operators are present in the v5.0 catalog (rhacs-operator and odf-operator are absent).Verification
cut -f2 -d.on "5.0.x")References
Summary by CodeRabbit
interop-opp-upgrade-awspolicies to usequay-operatorchannelstable-3.17for OCP 4.22 and OCP 5.0.