WIP: trying tls-scanner with strict Intermediate profile on monitoring stack - #82553
WIP: trying tls-scanner with strict Intermediate profile on monitoring stack#82553machine424 wants to merge 5 commits into
Conversation
openshift-ci
Bot
added
the
do-not-merge/work-in-progress
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughAdds optional user-workload monitoring configuration, wires the TLS scanner into the cluster monitoring e2e job, and updates scanner concurrency and CPU limits. ChangesMonitoring and TLS scanner integration
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 15✅ Passed checks (15 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
/pj-rehearse pull-ci-openshift-cluster-monitoring-operator-main-e2e-agnostic-operator |
|
@machine424: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/pj-rehearse pull-ci-openshift-cluster-monitoring-operator-main-e2e-agnostic-operator |
|
@machine424: your |
|
/pj-rehearse pull-ci-openshift-cluster-monitoring-operator-main-e2e-agnostic-operator |
|
@machine424: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: machine424 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 |
|
/pj-rehearse pull-ci-openshift-cluster-monitoring-operator-main-e2e-agnostic-operator |
|
@machine424: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/pj-rehearse pull-ci-openshift-cluster-monitoring-operator-main-e2e-agnostic-operator |
|
@machine424: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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/tls/scanner/run/tls-scanner-run-commands.sh`:
- Line 196: Update the scanner resource configuration near the cpu request so
the CPU limit uses the configured scanner_cpu value instead of the hardcoded 2.
Ensure the resulting pod always satisfies the request<=limit invariant, while
preserving the existing SCANNER_CPU default behavior.
🪄 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: Enterprise
Run ID: ed62125b-8ccd-49a8-b61d-45a9e2fca220
📒 Files selected for processing (1)
ci-operator/step-registry/tls/scanner/run/tls-scanner-run-commands.sh
| memory: ${scanner_memory} | ||
| limits: | ||
| cpu: "${scanner_cpu}" | ||
| cpu: "2" |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== file outline =="
wc -l ci-operator/step-registry/tls/scanner/run/tls-scanner-run-commands.sh
sed -n '150,220p' ci-operator/step-registry/tls/scanner/run/tls-scanner-run-commands.sh
echo
echo "== SCANNER_CPU references =="
rg -n "SCANNER_CPU|scanner_cpu|limits:|requests:" ci-operator/step-registry/tls/scanner/run/tls-scanner-run-commands.sh ci-operator/step-registry/tls/scanner -g '*.sh' -g '*.yaml' -g '*.yml'
echo
echo "== surrounding step-registry files =="
fd -t f . ci-operator/step-registry/tls/scannerRepository: openshift/release
Length of output: 5211
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== run ref yaml =="
sed -n '1,120p' ci-operator/step-registry/tls/scanner/run/tls-scanner-run-ref.yaml
echo
echo "== hypershift run ref yaml =="
sed -n '1,120p' ci-operator/step-registry/tls/scanner/hypershift-run/tls-scanner-hypershift-run-ref.yaml
echo
echo "== resource assignment logic =="
sed -n '60,85p' ci-operator/step-registry/tls/scanner/run/tls-scanner-run-commands.sh
echo
echo "== limit context =="
sed -n '186,200p' ci-operator/step-registry/tls/scanner/run/tls-scanner-run-commands.shRepository: openshift/release
Length of output: 6746
Align the scanner CPU limit with the configured request
SCANNER_CPU defaults to 4, so management runs create a pod with a 4 CPU request and a hardcoded 2 CPU limit. That violates the request<=limit invariant and can block the pod from starting. Keep the limit at ${scanner_cpu} or split request/limit into separate vars with an enforced ordering.
🤖 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/tls/scanner/run/tls-scanner-run-commands.sh` at
line 196, Update the scanner resource configuration near the cpu request so the
CPU limit uses the configured scanner_cpu value instead of the hardcoded 2.
Ensure the resulting pod always satisfies the request<=limit invariant, while
preserving the existing SCANNER_CPU default behavior.
|
/pj-rehearse pull-ci-openshift-cluster-monitoring-operator-main-e2e-agnostic-operator |
|
@machine424: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/pj-rehearse pull-ci-openshift-cluster-monitoring-operator-main-e2e-agnostic-operator |
|
@machine424: |
|
@machine424: your |
|
/pj-rehearse pull-ci-openshift-cluster-monitoring-operator-main-e2e-agnostic-operator |
|
@machine424: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
@machine424, |
INFO[2026-07-29T09:08:29Z] Running step e2e-agnostic-operator-tls-scanner-run. INFO[2026-07-29T09:31:32Z] Step e2e-agnostic-operator-tls-scanner-run succeeded after 23m2s.
|
/pj-rehearse pull-ci-openshift-cluster-monitoring-operator-main-e2e-agnostic-operator |
|
@machine424: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
[REHEARSALNOTIFIER]
A total of 33107 jobs have been affected by this change. The above listing is non-exhaustive and limited to 25 jobs. A full list of affected jobs can be found here Interacting with pj-rehearseComment: Once you are satisfied with the results of the rehearsals, comment: |
1 participant
Summary by CodeRabbit
This PR updates the OpenShift CI configuration for the cluster monitoring operator e2e flow to exercise the TLS scanner with a strict
IntermediateTLS profile. It adds atls-scanner-toolbase image for the monitoring/hypershift e2e job, updates thee2e-agnostic-operatortest wiring to runtls-scanner-run, and passes scan configuration via env vars (includingTLS_PROFILE_TYPE=Intermediate,PQC_CHECK=true,SCAN_NAMESPACE=openshift-monitoring,openshift-user-workload-monitoring,SCANNER_CPU=500m,SCANNER_MEMORY=1Gi, andENABLE_USER_WORKLOAD_MONITORING=true).The TLS scanner execution is also tuned for higher parallelism by running
tls-scannerwith-j 32, while setting the scanner container’s CPU limit to a fixed"2"(keeping the CPU request configurable).Additionally, it extends the IPI
ipi-install-monitoringpvcstep with an opt-inENABLE_USER_WORKLOAD_MONITORINGenv var (default"false"). When set to"true", the generatedcluster-monitoring-configpatch includesenableUserWorkload: true, enabling user workload monitoring for the installed cluster configuration.