ROX-35145: Use roxie in long-running release cluster setup#98
Open
porridge wants to merge 26 commits into
Open
ROX-35145: Use roxie in long-running release cluster setup#98porridge wants to merge 26 commits into
roxie in long-running release cluster setup#98porridge wants to merge 26 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:
📝 WalkthroughWalkthroughAdds a new ChangesNew roxie/install-cli Action
Migrate start-acs to roxie deploy
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
release/start-acs/action.yml (1)
43-57: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winInstall or guard
roxieinrelease/start-acs
start-acs.shcallsroxie deploydirectly, but this composite action never installs or checks forroxie. Add the install/check here so the action doesn’t depend on every caller setting up the CLI first.🤖 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 `@release/start-acs/action.yml` around lines 43 - 57, The start-acs composite action invokes start-acs.sh, which expects roxie to be available but does not install or verify it first. Update the launch-central step in action.yml to ensure roxie is installed or explicitly checked before running the script, so callers do not need to preconfigure the CLI. Use the existing start-acs.sh entrypoint and add the dependency handling in the composite action itself.
🧹 Nitpick comments (1)
roxie/install-cli/install-roxie.sh (1)
21-25: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winUnauthenticated GitHub API call is rate-limited and can flake on shared CI runners.
api.github.comallows only 60 requests/hour per source IP for unauthenticated calls; GitHub-hosted runners share egress IPs, so latest-version resolution can intermittently fail. Pass a token and guard an empty/nullresult so a bad response surfaces clearly instead of producing a malformedbase_url.♻️ Suggested hardening
if [[ -z "${ROXIE_VERSION:-}" ]]; then - ROXIE_VERSION=$(curl -fsSL --retry 5 --retry-all-errors \ - https://api.github.com/repos/stackrox/roxie/releases/latest | jq -r '.tag_name') + ROXIE_VERSION=$(curl -fsSL --retry 5 --retry-all-errors \ + ${GITHUB_TOKEN:+-H "Authorization: Bearer ${GITHUB_TOKEN}"} \ + https://api.github.com/repos/stackrox/roxie/releases/latest | jq -r '.tag_name') + if [[ -z "${ROXIE_VERSION}" || "${ROXIE_VERSION}" == "null" ]]; then + echo "::error::Failed to resolve latest roxie version" + exit 1 + fi echo "::notice::Resolved latest roxie version: ${ROXIE_VERSION}" fiWire
GITHUB_TOKENthrough the action'senvblock if you adopt this.🤖 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 `@roxie/install-cli/install-roxie.sh` around lines 21 - 25, The latest-version lookup in the ROXIE_VERSION initialization block is using an unauthenticated GitHub API request, which can be rate-limited on shared runners. Update the release query to use a token from GITHUB_TOKEN (and wire it through the action env if needed), then validate the jq result before assigning ROXIE_VERSION so empty or null responses fail clearly instead of flowing into a malformed base_url.
🤖 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 `@release/start-acs/roxie-config.yaml`:
- Around line 32-33: The static ROX_TELEMETRY_STORAGE_KEY_V1 entry in the roxie
config is now checked into the repo, so remove it from the committed YAML and
move it to a runtime-provided secret or rendered config path. Update the config
generation flow around the ROX_TELEMETRY_STORAGE_KEY_V1 setting so it is
injected from GitHub secrets or another secure source, or explicitly annotate
the config if this value is intended to be public/test-only.
In `@release/start-acs/start-acs.sh`:
- Around line 36-43: The temporary envrc created in the start-acs flow is left
behind if the script exits after sourcing it, which can leak ROX_ADMIN_PASSWORD.
Update the start-acs.sh flow around roxie_envrc and the roxie deploy/source
steps to register a cleanup handler that removes the generated temp file on
every exit path, including failures under set -e, and keep the cleanup tied to
the script’s normal teardown.
---
Outside diff comments:
In `@release/start-acs/action.yml`:
- Around line 43-57: The start-acs composite action invokes start-acs.sh, which
expects roxie to be available but does not install or verify it first. Update
the launch-central step in action.yml to ensure roxie is installed or explicitly
checked before running the script, so callers do not need to preconfigure the
CLI. Use the existing start-acs.sh entrypoint and add the dependency handling in
the composite action itself.
---
Nitpick comments:
In `@roxie/install-cli/install-roxie.sh`:
- Around line 21-25: The latest-version lookup in the ROXIE_VERSION
initialization block is using an unauthenticated GitHub API request, which can
be rate-limited on shared runners. Update the release query to use a token from
GITHUB_TOKEN (and wire it through the action env if needed), then validate the
jq result before assigning ROXIE_VERSION so empty or null responses fail clearly
instead of flowing into a malformed base_url.
🪄 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: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 9e12348d-d933-4f45-b737-11a36ef89ea6
📒 Files selected for processing (10)
.github/workflows/create-demo-clusters.ymlREADME.mdrelease/start-acs/action.ymlrelease/start-acs/patch-central.jsonrelease/start-acs/patch-sensor.jsonrelease/start-acs/roxie-config.yamlrelease/start-acs/start-acs.shroxie/install-cli/README.mdroxie/install-cli/action.ymlroxie/install-cli/install-roxie.sh
💤 Files with no reviewable changes (2)
- release/start-acs/patch-sensor.json
- release/start-acs/patch-central.json
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 @.github/workflows/test-roxie-start-acs.yml:
- Around line 20-21: The workflow inputs in the test-roxie-start-acs dispatch
currently use fixed cluster names, so every run reuses the same clusters and can
interfere with other validations. Update the values passed to the reusable
workflow for cluster creation so they are unique per dispatch, using a per-run
identifier or other generated suffix in the test-roxie-start-acs workflow’s
cluster name fields to avoid collisions across reruns and parallel runs.
- Line 13: The workflow currently uses secrets: inherit, which exposes all
dispatcher secrets instead of only the ones this job needs. Update the workflow
trigger/job configuration to pass only the explicitly required secrets for this
workflow, using the existing secret names referenced by the job such as
INFRA_TOKEN, GCP_RELEASE_AUTOMATION_SA, QUAY_RHACS_ENG_BEARER_TOKEN,
QUAY_RHACS_ENG_RO_USERNAME, QUAY_RHACS_ENG_RO_PASSWORD,
RELEASE_MANAGEMENT_PAGERDUTY_INTEGRATION_KEY, SLACK_BOT_TOKEN,
K6_ELASTICSEARCH_USER, K6_ELASTICSEARCH_PASSWORD, and K6_ELASTICSEARCH_URL.
🪄 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: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 6b814200-7675-411b-a0f4-a6e2f4c4af9b
📒 Files selected for processing (1)
.github/workflows/test-roxie-start-acs.yml
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/create-demo-clusters.yml (1)
373-373: 🩺 Stability & Availability | 🟠 Major | ⚡ Quick winPin the ROXIE CLI version here.
roxie/install-clidefaults to the latest release whenversionis omitted, so reruns can pick up a different binary and break deploy behavior.🤖 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 @.github/workflows/create-demo-clusters.yml at line 373, The ROXIE CLI install step is unpinned and will default to the latest release, which can make workflow reruns non-deterministic. Update the `roxie/install-cli` usage in `create-demo-clusters.yml` to pass an explicit version so the binary is stable across runs. Keep the change localized to the `install-cli` action invocation and make sure the selected version is consistent with the rest of the deployment workflow.
🧹 Nitpick comments (1)
.github/workflows/create-demo-clusters.yml (1)
142-147: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winDisable credential persistence on the local-action checkouts.
These checkouts are only used to read
.actions, so keeping the GitHub token in each cloned repo’s.git/configis unnecessary exposure. Settingpersist-credentials: falsehere addresses theartipackedwarning without changing behavior.Suggested hardening
- name: Checkout local action uses: actions/checkout@v4 with: repository: stackrox/actions path: .actions ref: ${{ inputs.workflow-ref || github.ref_name }} + persist-credentials: falseAlso applies to: 163-168, 225-230, 290-295, 315-320, 356-361, 449-454, 510-515, 558-563
🤖 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 @.github/workflows/create-demo-clusters.yml around lines 142 - 147, Disable credential persistence on the local action checkout steps used to populate .actions. Update each actions/checkout@v4 invocation in the workflow to set persist-credentials: false alongside the existing repository, path, and ref inputs so the GitHub token is not stored in .git/config while preserving behavior.Source: Linters/SAST tools
🤖 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 @.github/workflows/create-demo-clusters.yml:
- Around line 24-29: The new kube-burner config ref is only applied in one
place, so the central kube-burner checkout still uses the default version ref
while the secured-cluster path uses burner-ref. Update the central job’s
checkout logic in the create-demo-clusters workflow to consume the same parsed
kube-burner config ref output as the other job, using the existing
parse-refs/burner-ref wiring consistently. Make sure both jobs resolve the repo
and ref from the same inputs so manual overrides behave identically.
---
Outside diff comments:
In @.github/workflows/create-demo-clusters.yml:
- Line 373: The ROXIE CLI install step is unpinned and will default to the
latest release, which can make workflow reruns non-deterministic. Update the
`roxie/install-cli` usage in `create-demo-clusters.yml` to pass an explicit
version so the binary is stable across runs. Keep the change localized to the
`install-cli` action invocation and make sure the selected version is consistent
with the rest of the deployment workflow.
---
Nitpick comments:
In @.github/workflows/create-demo-clusters.yml:
- Around line 142-147: Disable credential persistence on the local action
checkout steps used to populate .actions. Update each actions/checkout@v4
invocation in the workflow to set persist-credentials: false alongside the
existing repository, path, and ref inputs so the GitHub token is not stored in
.git/config while preserving 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: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 7e3528d8-8098-4183-a08c-65b514395b7b
📒 Files selected for processing (1)
.github/workflows/create-demo-clusters.yml
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 @.github/workflows/create-demo-clusters.yml:
- Line 82: The Slack posting path in the `start-acs` job still runs even when
`properties` is skipped, so the manual `workflow_dispatch` flow can later read
an empty `needs.properties.outputs.slack-channel` value. Update the Slack step
in `create-demo-clusters.yml` to use the same skip condition as the `properties`
job, or add a check that `needs.properties.outputs.slack-channel` is non-empty
before posting, so the `start-acs` job does not attempt the Slack notification
when no channel is available.
🪄 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: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 180b6672-13c9-4868-ae05-ab78097c4240
📒 Files selected for processing (1)
.github/workflows/create-demo-clusters.yml
Replace the manual central.sh/sensor.sh/patch sequence with a single
`roxie deploy` invocation that handles operator installation, Central +
SecuredCluster deployment, readiness waiting, and LB detection.
The roxie config YAML captures what was previously spread across
action.yml env vars and patch-{central,sensor}.json files, including
PVC storage, resource limits, env vars, and scanner V4 settings.
Process baseline auto-locking uses the native CRD field.
Monitoring remains deployed via the stackrox Helm chart after ACS
is up, using envsubst for PagerDuty integration.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Dispatch wrapper for testing the create-demo-clusters reusable workflow from this branch. Remove after validation. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Add workflow_dispatch to create-demo-clusters.yml so it can be dispatched directly from feature branches. Remove standalone test workflow. All inputs fall back to sensible defaults for dispatch. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
These jobs require the calling repo's context (properties file, Quay bearer token). Skip them for direct dispatch testing. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Add !cancelled() && !failure() conditions so downstream jobs run when their dependencies are skipped (dispatch path) but still block when they actually fail (workflow_call path). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Roxie requires roxctl. Download it from the RHACS mirror matching the deployed version. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Return sooner without waiting for full scanner initialization. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The faster storage class doesn't exist on GKE clusters. premium-rwo is the GKE equivalent (SSD-backed). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This reverts commit 296804f.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replace sensor.sh/pull-secrets/kubectl-patches with roxie deploy secured-cluster. FACT container env vars use CRD overlays instead of kubectl set env (which the operator would reconcile away). Collector externalIps ConfigMap kept as-is (operator doesn't manage it). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Root cause: roxie uses API_ENDPOINT env var (not the CRD config's centralEndpoint) for roxctl CRS generation. Without it, roxctl gets an empty endpoint causing "missing port in address". Filed stackrox/roxie#230 for the UX issue. Fixes: - Add CA cert as base64-encoded output from start-acs - Decode CA cert in start-secured-cluster and set ROX_CA_CERT_FILE - Set API_ENDPOINT env var for roxie's roxctl CRS generation - Add --verbose to all roxie deploy calls Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Roxie auto-detects GKE infra clusters and applies medium resources, which combined with kube-burner workloads exceeds the 5-node e2-standard-8 cluster capacity. Use small profile to fit. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Remove resourceProfile: small (let operator use built-in defaults) - Add explicit central resources matching old patch-central.json (2 CPU / 3Gi requests, 4 CPU / 12Gi limits) - Add explicit sensor resources matching old patch-sensor.json - Enable scanner v2 (scannerComponent: Enabled) on both configs — small profile was disabling it Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Legacy roxctl-generate produces min=1/max=1 HPAs for scanner-v4 components (effectively no autoscaling) and min=1/max=5 for scanner. The operator defaults are min=2/max=5, causing extra replicas that exhaust cluster CPU. Set scaling to match legacy observations. Enable scanner v2 (scannerComponent: Enabled) which was missing. Keep central/sensor resource overrides matching the old patch JSON files. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The SecuredCluster CRD only accepts "AutoSense" or "Disabled" for scanner.scannerComponent (unlike the Central CRD which accepts "Enabled"). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Fake-load cluster: - scanner-v4-db CPU req: 500m (was operator default 1) - scanner-v4-indexer CPU req: 400m (was operator default 1500m) - scanner-v4-matcher CPU req: 400m (was operator default 500m) Real-load cluster: - sensor: 500m/4 CPU, 500Mi/8Gi (was 2/4, 3Gi/12Gi from patch-sensor.json which only applies to fake-load) - admission-control mem limit: 500Mi (was operator default 1Gi) - scanner HPA min: 2 (was 1) - scanner-v4-indexer HPA: Enabled min=2/max=5 (was Disabled) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Add testing instructions comment near workflow_dispatch trigger - Reorder dispatch inputs to match workflow_call order - Consolidate roxie config comments to a single header explaining that resource settings match the previous deploy-scripts-based flow and may be tuned in the future Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
porridge
force-pushed
the
use-roxie-in-start-acs
branch
from
04591ad to
d86a4e4
Compare
porridge
changed the title
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Contributor
Author
|
@CodeRabbit-ai review |
porridge
changed the title
roxie in long-running release cluster setup
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
.github/workflows/create-demo-clusters.yml (1)
563-589: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
start-kube-burner-for-centralstill checks out kube-burner config withversion-ref, notburner-ref.This is the same issue raised in a prior review (marked "Addressed") for the central job specifically. The sibling job
start-kube-burner-for-secured-clusterwas fixed to useneeds.parse-refs.outputs.burner-ref(Line 528), but Line 583 here still usesneeds.parse-refs.outputs.version-ref. Whenkube-burner-config-refis manually overridden and differs fromversion, the central job will pull the wrong kube-burner config ref, causing inconsistent behavior between the two kube-burner jobs (and potential failures if the alternate repo lacks the stackrox version tag).🐛 Proposed fix
- name: Check out kube-burner config repository code uses: actions/checkout@v4 with: repository: stackrox/${{ inputs.kube-burner-config-repo }} path: .kube-burner-config - ref: ${{ needs.parse-refs.outputs.version-ref }} + ref: ${{ needs.parse-refs.outputs.burner-ref }}🤖 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 @.github/workflows/create-demo-clusters.yml around lines 563 - 589, The start-kube-burner-for-central job is still checking out the kube-burner config repository with the wrong ref, so update the actions/checkout step in that job to use needs.parse-refs.outputs.burner-ref instead of version-ref. Keep it aligned with start-kube-burner-for-secured-cluster and ensure the kube-burner config checkout in start-kube-burner-for-central uses the burner ref when locating the repository.
🧹 Nitpick comments (2)
release/start-secured-cluster/action.yml (1)
47-53: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winPass
ca-certvia env instead of inline${{ }}interpolation.Interpolating action inputs directly into an inline
runblock is a script-injection anti-pattern in GitHub Actions. The value here is Base64 (safe alphabet), so it isn't exploitable today, but binding it throughenvavoids the pattern and is more robust to future input changes.🔒 Proposed fix
- name: Decode CA certificate id: ca-cert shell: bash + env: + CA_CERT: ${{ inputs.ca-cert }} run: | ca_cert_file="$(mktemp)" - echo "${{ inputs.ca-cert }}" | base64 -d > "$ca_cert_file" + echo "$CA_CERT" | base64 -d > "$ca_cert_file" echo "file=$ca_cert_file" >> "$GITHUB_OUTPUT"🤖 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 `@release/start-secured-cluster/action.yml` around lines 47 - 53, The “Decode CA certificate” step in action.yml should stop interpolating inputs directly inside the inline shell script. Bind the ca-cert input through the step’s env map and reference that environment variable inside the run block instead of using the `${{ inputs.ca-cert }}` expression in the script. Keep the existing output behavior from the ca-cert step unchanged while updating the shell command to read from the env-backed value..github/workflows/create-demo-clusters.yml (1)
156-161: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winLocal-action checkouts don't set
persist-credentials: false.All "Checkout local action" steps (stackrox/actions) use
actions/checkout@v4withoutpersist-credentials: false, leaving the auth token in the local git config for the remainder of the job (flagged by zizmor asartipackedacross all listed line ranges). Consider addingpersist-credentials: falseto these steps since they don't need to push back to the checked-out repo.🔒 Proposed fix (repeat for each occurrence)
- name: Checkout local action uses: actions/checkout@v4 with: repository: stackrox/actions path: .actions ref: ${{ inputs.workflow-ref || github.ref_name }} + persist-credentials: falseAlso applies to: 177-182, 240-245, 307-312, 333-338, 376-381, 471-476, 535-540, 584-589
🤖 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 @.github/workflows/create-demo-clusters.yml around lines 156 - 161, The “Checkout local action” steps in the workflow use actions/checkout@v4 without disabling credential persistence, which leaves the auth token in git config for the rest of the job. Update each stackrox/actions checkout block to set persist-credentials to false, keeping the existing repository, path, and ref settings unchanged.Source: Linters/SAST tools
🤖 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 @.github/workflows/create-demo-clusters.yml:
- Around line 174-182: Add the same workflow status guard to the
create-os4-cluster job so it behaves consistently with the other cluster jobs.
Update the job condition on create-os4-cluster to include !cancelled() &&
!failure() alongside the existing dry-run and create-os4-cluster input checks,
using the create-os4-cluster and notify-os4-cluster job flow as the reference.
This will prevent the skipped wait-for-images dependency from cascading into an
unintended skip during manual dispatch.
In `@release/start-secured-cluster/start-secured-cluster.sh`:
- Around line 19-25: The roxctl install step in the secured cluster startup
script assumes ~/.local/bin already exists, so the curl download can fail on
fresh runner images. Update the install block around the roxctl check to create
the target directory first with a mkdir -p for ~/.local/bin before writing the
roxctl binary, keeping the existing curl and chmod flow intact.
---
Duplicate comments:
In @.github/workflows/create-demo-clusters.yml:
- Around line 563-589: The start-kube-burner-for-central job is still checking
out the kube-burner config repository with the wrong ref, so update the
actions/checkout step in that job to use needs.parse-refs.outputs.burner-ref
instead of version-ref. Keep it aligned with
start-kube-burner-for-secured-cluster and ensure the kube-burner config checkout
in start-kube-burner-for-central uses the burner ref when locating the
repository.
---
Nitpick comments:
In @.github/workflows/create-demo-clusters.yml:
- Around line 156-161: The “Checkout local action” steps in the workflow use
actions/checkout@v4 without disabling credential persistence, which leaves the
auth token in git config for the rest of the job. Update each stackrox/actions
checkout block to set persist-credentials to false, keeping the existing
repository, path, and ref settings unchanged.
In `@release/start-secured-cluster/action.yml`:
- Around line 47-53: The “Decode CA certificate” step in action.yml should stop
interpolating inputs directly inside the inline shell script. Bind the ca-cert
input through the step’s env map and reference that environment variable inside
the run block instead of using the `${{ inputs.ca-cert }}` expression in the
script. Keep the existing output behavior from the ca-cert step unchanged while
updating the shell command to read from the env-backed value.
🪄 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: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: dde1062a-2afb-45ba-83f6-b8d20699fe20
📒 Files selected for processing (9)
.github/workflows/create-demo-clusters.ymlrelease/start-acs/action.ymlrelease/start-acs/patch-central.jsonrelease/start-acs/patch-sensor.jsonrelease/start-acs/roxie-config.yamlrelease/start-acs/start-acs.shrelease/start-secured-cluster/action.ymlrelease/start-secured-cluster/roxie-config.yamlrelease/start-secured-cluster/start-secured-cluster.sh
💤 Files with no reviewable changes (2)
- release/start-acs/patch-sensor.json
- release/start-acs/patch-central.json
🚧 Files skipped from review as they are similar to previous changes (1)
- release/start-acs/start-acs.sh
porridge
changed the title
roxie in long-running release cluster setuproxie in long-running release cluster setup
vikin91
reviewed
Jul 6, 2026
vikin91
left a comment
vikin91
left a comment
Contributor
There was a problem hiding this comment.
Test plan
I would like to make sure that the validation of this PR included:
- Starting a long running cluster
- Confirming that the both workflows (fake and berserker) are working and generating load.
The current shape of the "Test plan" section doesn't say that - could we confirm this?
Contributor
Author
Right, I did this part. The first two first two boxes try to reflect this.
Good point. I can spin them up, but likely will need some help making sure they are indeed working as expected. Is this something you have experience in @vikin91 ? |
vikin91
reviewed
Jul 6, 2026
Comment on lines
+7
to
+14
| sensor: | ||
| resources: | ||
| requests: | ||
| memory: "500Mi" | ||
| cpu: "500m" | ||
| limits: | ||
| memory: "8Gi" | ||
| cpu: "4" |
Contributor
There was a problem hiding this comment.
Those are different values than in release/start-acs/patch-sensor.json. We are comparing past runs against the new ones, so I think it is important to keep the same resources settings - especially for Sensor which would consume tons of memory in the long-running cluster.
Contributor
Author
There was a problem hiding this comment.
Hm, these values were taken from an actual cluster created with this workflow.
I investigated deeper, and:
- the
release/start-acs/*-patch.jsonfiles have no relation to the roxie config we're commenting on, because the config belongs to a different job - even for the
start-acsjob's roxie config they do not matter a lot, because towards the end the job runs a funny little script which joyfully patches the resources again -- to completely different values! - either way, the operator is going to restore the values whenever it feels like it, so I need to pause reconciliation when deployment is up. It was and is a waste of time, but not something I'd like to refactor in scope of this PR.
I'm addressing this in 3d3837e
Will ping you on slack when the clusters are up.
vikin91
reviewed
Jul 6, 2026
Contributor
Yes, I do, but I am sure that you can spot Sensor consuming tons of memory very quickly (~1-2 hrs) yourself :) |
Enable pauseReconciliation on both Central and SecuredCluster CRs so that post-deploy patches (from launch_workload.sh) persist instead of being reconciled away by the operator. Set central-db resources to match legacy ci-values (1 CPU / 1Gi requests) rather than the operator Helm chart default (4 CPU / 8Gi). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The install-cli action's latest-version lookup hits unauthenticated GitHub API rate limits when multiple jobs run in parallel. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
porridge
changed the title
roxie in long-running release cluster setuproxie in long-running release cluster setup
Contributor
|
Partial update:
then go to https://localhost:48444/dashboards Pre-roxie: Post-roxie: but metrics indicate that fake workloads work: 8M enrichments of network flows over night looks as expected for fake workloads. |
Prometheus was unable to scrape StackRox metrics because the monitoring ports and network policy rules were missing. Enable exposeEndpoint on central, scanner, scannerV4 components, and use overlays to add the monitoring port to the sensor service and allow ingress on port 9090 in the sensor network policy. Partially generated by AI.
Contributor
Author
|
@vikin91 I found the cause - missing monitoring port definitions on deployments. Fixed in the last commit. I'll set up a fresh new set of clusters. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Replaces the legacy deploy-scripts-based flow (
central.sh,sensor.sh,deploy.sh,kubectl patches) in both
release/start-acsandrelease/start-secured-clusterwithroxie — a single
roxie deployinvocation per component.start-acs (fake-load cluster: Central + SecuredCluster)
roxie deploy centralreplaces central.sh + sensor.sh + kubectl patchesroxctlfrom RHACS mirror (required by roxie)start-secured-cluster (real-load cluster: SecuredCluster only)
roxie deploy secured-clusterreplaces sensor.sh + kubectl patchesAPI_ENDPOINTandROX_CA_CERT_FILEenv vars for CRS generation(see Multi-cluster secured-cluster deploy fails with cryptic error when following docs roxie#230 for a UX improvement filed)
roxie-config.yaml (both actions)
flow — verified with 100% alignment against a legacy baseline deployment (every
deployment container's CPU/memory requests and limits, plus HPA min/max, match exactly)
Deleted files
release/start-acs/patch-central.jsonandrelease/start-acs/patch-sensor.json— settings now in respectiveroxie-config.yamlTest scaffolding
Useful for testing this workflow.
workflow_dispatchtrigger tocreate-demo-clusters.ymlwith testinginstructions in a comment
!cancelled() && !failure()conditions on jobs that depend onpropertiesand
wait-for-images(skipped in direct dispatch since those require the callingrepo's context)
if: needs.properties.outputs.slack-channel != ''on Slack stepsroxie/install-clistep before both start-acs and start-secured-clusterin the workflow
Resource alignment verification
Deployed both legacy (deploy-scripts) and roxie side-by-side on identical GKE clusters
(5x e2-standard-8) with ACS 4.11.0. Compared every deployment container's CPU/memory
requests and limits, plus HPA min/max replicas:
Run: https://github.com/stackrox/stackrox/actions/runs/28577578264
Test plan
create-demo-clustersworkflow end-to-end (all jobs pass)🤖 Generated with Claude Code