monitoring: CMO: add TLS scanner step to e2e-agnostic-operator presubmit - #82553
monitoring: CMO: add TLS scanner step to e2e-agnostic-operator presubmit#82553machine424 wants to merge 2 commits into
Conversation
|
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. |
|
/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. |
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, |
|
/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. |
Align the step-registry env vars with the upstream tls-scanner change (openshift/tls-scanner#87) that splits SCANNER_CPU / SCANNER_MEMORY into separate request and limit variables. New variables (both run and hypershift-run refs): SCANNER_CPU_REQUEST / SCANNER_CPU_LIMIT (default 4 / 4) SCANNER_MEM_REQUEST / SCANNER_MEM_LIMIT (default 4Gi / 4Gi) New guest-cluster variables (hypershift-run ref only): SCANNER_CPU_GUEST_REQUEST / SCANNER_CPU_GUEST_LIMIT (default 1 / 1) SCANNER_MEM_GUEST_REQUEST / SCANNER_MEM_GUEST_LIMIT (default 2Gi / 2Gi) The original SCANNER_CPU, SCANNER_MEMORY, SCANNER_CPU_GUEST, and SCANNER_MEMORY_GUEST are preserved as deprecated fallbacks so that existing CI configs continue to work without changes. This unblocks openshift#82553 (add tls-scanner to cluster-monitoring-operator e2e) which uses the new split vars to set a lower CPU request for scheduling while keeping a higher burst limit.
Align the step-registry env vars with the upstream tls-scanner change (openshift/tls-scanner#87) that splits SCANNER_CPU / SCANNER_MEMORY into separate request and limit variables. New variables (both run and hypershift-run refs): SCANNER_CPU_REQUEST / SCANNER_CPU_LIMIT (default 4 / 4) SCANNER_MEM_REQUEST / SCANNER_MEM_LIMIT (default 4Gi / 4Gi) New guest-cluster variables (hypershift-run ref only): SCANNER_CPU_GUEST_REQUEST / SCANNER_CPU_GUEST_LIMIT (default 1 / 1) SCANNER_MEM_GUEST_REQUEST / SCANNER_MEM_GUEST_LIMIT (default 2Gi / 2Gi) The original SCANNER_CPU, SCANNER_MEMORY, SCANNER_CPU_GUEST, and SCANNER_MEMORY_GUEST are preserved as deprecated fallbacks so that existing CI configs continue to work without changes. This unblocks openshift#82553 (add tls-scanner to cluster-monitoring-operator e2e) which uses the new split vars to set a lower CPU request for scheduling while keeping a higher burst limit.
Align the step-registry env vars with the upstream tls-scanner change (openshift/tls-scanner#87) that splits SCANNER_CPU / SCANNER_MEMORY into separate request and limit variables. New variables (both run and hypershift-run refs): SCANNER_CPU_REQUEST / SCANNER_CPU_LIMIT (default 4 / 4) SCANNER_MEM_REQUEST / SCANNER_MEM_LIMIT (default 4Gi / 4Gi) New guest-cluster variables (hypershift-run ref only): SCANNER_CPU_GUEST_REQUEST / SCANNER_CPU_GUEST_LIMIT (default 1 / 1) SCANNER_MEM_GUEST_REQUEST / SCANNER_MEM_GUEST_LIMIT (default 2Gi / 2Gi) The original SCANNER_CPU, SCANNER_MEMORY, SCANNER_CPU_GUEST, and SCANNER_MEMORY_GUEST are preserved as deprecated fallbacks so that existing CI configs continue to work without changes. This unblocks openshift#82553 (add tls-scanner to cluster-monitoring-operator e2e) which uses the new split vars to set a lower CPU request for scheduling while keeping a higher burst limit.
…82865) Align the step-registry env vars with the upstream tls-scanner change (openshift/tls-scanner#87) that splits SCANNER_CPU / SCANNER_MEMORY into separate request and limit variables. New variables (both run and hypershift-run refs): SCANNER_CPU_REQUEST / SCANNER_CPU_LIMIT (default 4 / 4) SCANNER_MEM_REQUEST / SCANNER_MEM_LIMIT (default 4Gi / 4Gi) New guest-cluster variables (hypershift-run ref only): SCANNER_CPU_GUEST_REQUEST / SCANNER_CPU_GUEST_LIMIT (default 1 / 1) SCANNER_MEM_GUEST_REQUEST / SCANNER_MEM_GUEST_LIMIT (default 2Gi / 2Gi) The original SCANNER_CPU, SCANNER_MEMORY, SCANNER_CPU_GUEST, and SCANNER_MEMORY_GUEST are preserved as deprecated fallbacks so that existing CI configs continue to work without changes. This unblocks #82553 (add tls-scanner to cluster-monitoring-operator e2e) which uses the new split vars to set a lower CPU request for scheduling while keeping a higher burst limit. Co-authored-by: Chai Bot <ship-help-github@redhat.com>
…penshift#82865) Align the step-registry env vars with the upstream tls-scanner change (openshift/tls-scanner#87) that splits SCANNER_CPU / SCANNER_MEMORY into separate request and limit variables. New variables (both run and hypershift-run refs): SCANNER_CPU_REQUEST / SCANNER_CPU_LIMIT (default 4 / 4) SCANNER_MEM_REQUEST / SCANNER_MEM_LIMIT (default 4Gi / 4Gi) New guest-cluster variables (hypershift-run ref only): SCANNER_CPU_GUEST_REQUEST / SCANNER_CPU_GUEST_LIMIT (default 1 / 1) SCANNER_MEM_GUEST_REQUEST / SCANNER_MEM_GUEST_LIMIT (default 2Gi / 2Gi) The original SCANNER_CPU, SCANNER_MEMORY, SCANNER_CPU_GUEST, and SCANNER_MEMORY_GUEST are preserved as deprecated fallbacks so that existing CI configs continue to work without changes. This unblocks openshift#82553 (add tls-scanner to cluster-monitoring-operator e2e) which uses the new split vars to set a lower CPU request for scheduling while keeping a higher burst limit. Co-authored-by: Chai Bot <ship-help-github@redhat.com>
…penshift#82865) Align the step-registry env vars with the upstream tls-scanner change (openshift/tls-scanner#87) that splits SCANNER_CPU / SCANNER_MEMORY into separate request and limit variables. New variables (both run and hypershift-run refs): SCANNER_CPU_REQUEST / SCANNER_CPU_LIMIT (default 4 / 4) SCANNER_MEM_REQUEST / SCANNER_MEM_LIMIT (default 4Gi / 4Gi) New guest-cluster variables (hypershift-run ref only): SCANNER_CPU_GUEST_REQUEST / SCANNER_CPU_GUEST_LIMIT (default 1 / 1) SCANNER_MEM_GUEST_REQUEST / SCANNER_MEM_GUEST_LIMIT (default 2Gi / 2Gi) The original SCANNER_CPU, SCANNER_MEMORY, SCANNER_CPU_GUEST, and SCANNER_MEMORY_GUEST are preserved as deprecated fallbacks so that existing CI configs continue to work without changes. This unblocks openshift#82553 (add tls-scanner to cluster-monitoring-operator e2e) which uses the new split vars to set a lower CPU request for scheduling while keeping a higher burst limit. Co-authored-by: Chai Bot <ship-help-github@redhat.com>
…penshift#82865) Align the step-registry env vars with the upstream tls-scanner change (openshift/tls-scanner#87) that splits SCANNER_CPU / SCANNER_MEMORY into separate request and limit variables. New variables (both run and hypershift-run refs): SCANNER_CPU_REQUEST / SCANNER_CPU_LIMIT (default 4 / 4) SCANNER_MEM_REQUEST / SCANNER_MEM_LIMIT (default 4Gi / 4Gi) New guest-cluster variables (hypershift-run ref only): SCANNER_CPU_GUEST_REQUEST / SCANNER_CPU_GUEST_LIMIT (default 1 / 1) SCANNER_MEM_GUEST_REQUEST / SCANNER_MEM_GUEST_LIMIT (default 2Gi / 2Gi) The original SCANNER_CPU, SCANNER_MEMORY, SCANNER_CPU_GUEST, and SCANNER_MEMORY_GUEST are preserved as deprecated fallbacks so that existing CI configs continue to work without changes. This unblocks openshift#82553 (add tls-scanner to cluster-monitoring-operator e2e) which uses the new split vars to set a lower CPU request for scheduling while keeping a higher burst limit. Co-authored-by: Chai Bot <ship-help-github@redhat.com>
|
/retest |
|
/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. |
There was a problem hiding this comment.
for completeness we need also to enable UWM Alertmanager.
There was a problem hiding this comment.
I try to do that in the UWM step
There was a problem hiding this comment.
it's a bit disturbing that a step to configure monitoring PVC can also enable user-workload monitoring. Should we have our own separate step?
There was a problem hiding this comment.
Good catch, yes we can make things cleaner
Add the tls-scanner-run step (strict Intermediate profile) to the e2e-agnostic-operator test so it executes on every PR. While the scanner already runs as a periodic, having it in a presubmit catches TLS regressions before merge instead of after. The step scans both the Platform (openshift-monitoring) and UWM (openshift-user-workload-monitoring) stacks and adds ~10 minutes to the job. The scanner only needs to run in CMO CI, not in operand-specific ones (Prometheus, Alertmanager), since all TLS configuration is applied on the CMO side. Add ipi-install-monitoring-uwm to the ipi-conf-aws chain. The step generates install-time manifests to enable the full UWM stack (UWM + UWM Alertmanager). It defaults to off and is a no-op unless ENABLE_USER_WORKLOAD_MONITORING is set to true.
Update OWNERS for ipi-install-monitoringpvc and ipi-install-monitoring-uwm.
|
/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 |
There was a problem hiding this comment.
@simonpasquier this would add the step to thousands of jobs
maybe we can just override our own chain for cmo agnostic, the steps don;t seem to change a lot
|
[REHEARSALNOTIFIER]
A total of 15928 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: |
|
@machine424: 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. |
CMO: add TLS scanner step to e2e-agnostic-operator presubmit
Add the
tls-scanner-runstep (strict Intermediate profile) to thee2e-agnostic-operatortest so it executes on every PR. While thescanner already runs as a periodic, having it in a presubmit catches
TLS regressions before merge instead of after.
The step scans both the Platform (
openshift-monitoring) and UWM(
openshift-user-workload-monitoring) stacks and adds ~10 minutes tothe job.
The scanner only needs to run in CMO CI, not in operand-specific ones
(Prometheus, Alertmanager), since all TLS configuration is applied on
the CMO side.
ipi-install-monitoring-uwm
Add
ipi-install-monitoring-uwmto theipi-conf-awschain. The stepgenerates install-time manifests to enable the full UWM stack (UWM +
UWM Alertmanager). It defaults to off and is a no-op unless
ENABLE_USER_WORKLOAD_MONITORINGis set to"true".TLS Scanner benchmarks
2b34dbedb27979760610bf0f27830335b3d9f7533793c64bSee also #82865