opendatahub-operator: drop cleanup-olm-catalog workaround step - #83457
opendatahub-operator: drop cleanup-olm-catalog workaround step#83457ugiordan wants to merge 1 commit into
Conversation
|
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 with no reviewable changes (1)
WalkthroughThe operator CI configuration adds a TLS scanner image and post-step. It updates standard and RHOAI E2E jobs with automatic resource resolution and broader skip patterns. RHOAI jobs also receive scan variables and Quay pull-secret preparation. ChangesOperator CI configuration
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This change removes an unnecessary catalog cleanup step and relies on the scanner’s existing handling for non-TLS endpoints. No actionable merge-blocking risk remains beyond normal checks and review. 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 |
|
@ugiordan, Interacting with pj-rehearseComment: Once you are satisfied with the results of the rehearsals, comment: |
The cleanup-olm-catalog step deletes CatalogSource pods before running tls-scanner to avoid false positives from the OLM catalog pod serving plain gRPC on port 50051. Investigation shows this was never necessary: NO_TLS ports were never a failure in the scanner, only informational output in the scan log. The actual failures that caused the scanner to be reverted in July were rhods-operator:8080 plain HTTP endpoints, which are now fixed (operator metrics moved to :8443 with TLS). Remove the destructive workaround. Co-Authored-By: Claude <claude-sonnet-4-6> <noreply@anthropic.com>
241eb70 to
9557cfc
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. |
|
[REHEARSALNOTIFIER]
Interacting with pj-rehearseComment: Once you are satisfied with the results of the rehearsals, comment: |
|
/pj-rehearse |
|
@carlkyrillos: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
Makes sense. Thanks for the cleanup! NO_TLS status should always result in a SKIP rather than failing the test. |
|
/lgtm |
|
Feel free to rehearsal-ack if the compliance failures are accurate (no false failures). |
|
/pj-rehearse pull-ci-opendatahub-io-opendatahub-operator-main-opendatahub-operator-rhoai-e2e |
|
@ugiordan: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
@ugiordan: all tests passed! 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. |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: carlkyrillos, richardsonnick, ugiordan 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 |
The
cleanup-olm-catalogstep deletes CatalogSource pods beforetls-scanner-runto avoid apparent false positives from the OLM catalog pod serving plain gRPC on port 50051.Investigation shows this step was never needed:
NO_TLSports produced a passing (empty) JUnit testcase with no failure element. The scanner'sHasComplianceFailuresfunction only returns non-zero for ports where TLS was detected but didn't meet the cluster profile — a non-TLS port never triggers that path.NO_TLSports emit an explicit<skipped>JUnit element. Still not a failure.The actual failures that caused the scanner to be reverted in July (#82675) were
rhods-operator:8080plain HTTP endpoints. Those are now fixed — the operator metrics endpoint moved to:8443with TLS. The catalog pod was noise in the scan log, not the root cause.Dropping the destructive workaround and relying on the scanner's existing
NO_TLShandling./cc @richardsonnick @rhmdnd
Summary by CodeRabbit
The
opendatahub-operatorRHOAI end-to-end job now runs the TLS scanner without deleting CatalogSource pods first. This removes thecleanup-olm-catalogworkaround becauseNO_TLSresults do not produce scanner failures, and the affectedrhods-operatorendpoint now uses TLS on port8443.The CI configuration also adds the TLS scanner image, scan environment variables, Quay pull-secret setup, automatic E2E resource resolution, and updated file-change and image-mirror skip patterns.