Bug OCPBUGS-104497: Fix [sig-ci] prow job name OS version test for 4.23 rhcos9 - #31481
Bug OCPBUGS-104497: Fix [sig-ci] prow job name OS version test for 4.23 rhcos9#31481redhat-chai-bot wants to merge 1 commit into
Conversation
|
Pipeline controller notification For optional jobs, comment This repository is configured in: automatic mode |
openshift-ci
Bot
added
the
ready-for-human-review
openshift-ci-robot
added
jira/valid-reference
|
@redhat-chai-bot: This pull request references Jira Issue OCPBUGS-104497, which is invalid:
Comment The bug has been updated to refer to the pull request using the external bug tracker. 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)
Walkthrough
ChangesStandalone node OS selection
Estimated code review effort: 2 (Simple) | ~5 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 15✅ Passed checks (15 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}
|
Scheduling required tests: |
|
/retest-required GCP job failures are infra-related (node provisioning timeout: "6 ready nodes expected, found 5"), not caused by this change. All AWS/vSphere/metal jobs passed. AI-generated. Review for accuracy. |
|
/test e2e-gcp-csi AI-generated. Review for accuracy. |
|
/payload-job periodic-ci-openshift-release-main-ci-4.23-e2e-aws-ovn-techpreview |
|
@neisw: trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/a13fb8c0-904f-11f1-864b-9ddbddabc300-0 |
| // For non-upgrade, non-explicit-rhcos jobs: 4.x clusters default to rhel-9 | ||
| desiredVersion, err := utilversion.ParseGeneric(clusterVersion.Status.Desired.Version) |
There was a problem hiding this comment.
@redhat-chai-bot Is there a good reason for having separate branches for upgrade and "else if current version < 5"?
It seems to me that we can have a single "if was installed as <5 then expect rhel-9" (unless explicit, per rhcos10 marker, handled by earlier branch), and maybe just add a comment/log about the upgrade special case (OCP5 clusters will have RHEL9 if they were installed as OCP4 and upgraded)
There was a problem hiding this comment.
Good question. Yes, there is a reason they're separate: for upgrade tests (4.x → 5.x), the cluster's desiredVersion after upgrade is 5.x, so the Major() < 5 check in the else branch would be false — it would incorrectly default to rhel-10. But the MCP stream is still rhel-9 because that's what was originally installed. The upgrade branch catches this via the job name.
In other words:
- Upgrade job (4.x→5.x):
desiredVersion= 5.x, MCP stream = rhel-9 → needs job-name-based detection - Non-upgrade 4.x job:
desiredVersion= 4.x, MCP stream = rhel-9 → caught by version check
A single "if was installed as <5" branch could work if we checked the ClusterVersion's .status.history for the original installation version instead of desired.version, but that's a bigger change. Happy to refactor that way if you'd prefer, or we could add a comment here explaining the distinction and consider the consolidation as a follow-up.
AI-generated. Review for accuracy.
There was a problem hiding this comment.
@redhat-chai-bot if we only check the installation version through the helper then we do not need to care about desired version at all
There was a problem hiding this comment.
You're right — checking the installation version through the ClusterVersion history would let us consolidate the upgrade and else branches into a single check. I'll refactor to use .status.history to find the initial installation version. If its Major < 5, we expect rhel-9 regardless of whether it's an upgrade or not.
Working on this now.
AI-generated. Review for accuracy.
|
/test e2e-gcp-csi AI-generated. Review for accuracy. |
|
/jira refresh |
openshift-ci-robot
added
jira/valid-bug
|
@petr-muller: This pull request references Jira Issue OCPBUGS-104497, which is valid. The bug has been moved to the POST state. 3 validation(s) were run on this bug
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. |
…23 rhcos9 4.23 nightly jobs now run with RHCOS 9 (rhel-9 stream). The validateStandaloneNodeOS check defaulted the expected stream to rhel-10 for jobs without an explicit rhcos9/rhcos10 marker, causing all 4.23 e2e jobs to fail with 'MCP master uses rhel-9 as stream but was expecting rhel-10'. Add an else clause so non-upgrade, non-explicit-rhcos jobs on 4.x clusters (Major < 5) default to rhel-9.
4b6c842 to
b67e0bd
Compare
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
|
/payload-job periodic-ci-openshift-release-main-ci-5.0-e2e-aws-ovn periodic-ci-openshift-release-main-ci-5.0-upgrade-from-stable-4.22-e2e-aws-ovn-upgrade periodic-ci-openshift-release-main-ci-4.23-upgrade-from-stable-4.22-e2e-aws-ovn-upgrade periodic-ci-openshift-release-main-nightly-4.23-e2e-aws-ovn-serial-1of2 AI-generated. Review for accuracy. |
|
@redhat-chai-bot: trigger 4 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/72f92be0-90c7-11f1-8e18-dc1dc88e9af8-0 |
|
@redhat-chai-bot: This pull request references Jira Issue OCPBUGS-104497, which is valid. 3 validation(s) were run on this bug
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. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: petr-muller, redhat-chai-bot 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 |
openshift-ci
Bot
added
the
approved
|
Scheduling required tests: |
4 participants
Summary
4.23 nightly jobs now run with RHCOS 9 (
rhel-9stream), but the[sig-ci] [Early] prow job name should match os versiontest invalidateStandaloneNodeOSdefaults to expectingrhel-10when the job name has no explicitrhcos9/rhcos10marker. This causes a permafail across all 4.23 e2e jobs starting with payload4.23.0-0.nightly-2026-08-01-032511.Root Cause
The if/else chain in
validateStandaloneNodeOSthat determines the expectedtargetStreamhandles explicit markers (rhcos9,rhcos10),-runcjobs (#31479), andupgradejobs. For all other jobs it falls through to therhel-10default — which is correct for 5.0+ but wrong for 4.23 (which is still a 4.x release running RHEL 9).The error:
Fix
Added an
elseclause that checks the cluster's desired version: ifMajor < 5, defaulttargetStreamtorhel-9. This correctly handles 4.23 (and any future 4.x releases) without affecting 5.0+ jobs.Testing
go vet ./test/extended/ci/...— passesgo test ./test/extended/ci/...— passes (no unit test files for this Ginkgo e2e package, but compiles cleanly)References
AI-generated. Review for accuracy.
@petr-muller requested in Slack thread
Summary by CodeRabbit