ROX-35145: Use roxie in long-running release cluster setup#98
ROX-35145: Use roxie in long-running release cluster setup#98porridge wants to merge 34 commits into
roxie in long-running release cluster setup#98Conversation
|
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 |
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>
04591ad to
d86a4e4
Compare
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
@CodeRabbit-ai review |
roxie in long-running release cluster setup
roxie in long-running release cluster setuproxie in long-running release cluster setup
vikin91
left a comment
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?
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 ? |
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>
roxie in long-running release cluster setuproxie in long-running release cluster setup
|
Partial update:
then go to https://localhost:48444/dashboards 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.
|
@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. |
vikin91
left a comment
There was a problem hiding this comment.
Looks good! I looked at the deployed clusters and could confirm that the fake-workloads and real workloads are running.
However, I found some issues in this action (with 🤖 ). None of them are blocking, but the:
- create-os4-cluster guard and
- version-ref/burner-ref mixup
are worth fixing.
Rest are nits (which are also worth fixing 😉 )
| MONITORING_SUPPORT: "true" # Runs monitoring | ||
| LOAD_BALANCER: lb | ||
| SECURED_CLUSTER_AUTO_LOCK_PROCESS_BASELINES: "true" | ||
| ROX_ADMIN_USERNAME: admin |
There was a problem hiding this comment.
Can you comment in the PR why these environment variables are being removed and what impact removing them will have? Some of them may be in the roxie config. Others are being removed entirely.
Also there are comments for some of these in start-acs.sh. You will need to remove those.
There was a problem hiding this comment.
Added a table to the PR description, and updated the comments.
Strip workflow_dispatch trigger, conditional skips, Slack guards, and ref fallbacks. Only keep the two roxie/install-cli steps and the ca-cert output/input plumbing needed for production use. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Roxie v0.4.3 bundles roxctl internally, so the separate install from the RHACS mirror is no longer needed. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Remove stale env var comments that referenced the legacy deploy scripts (ROX_IMAGE_FLAVOR, STORAGE, STORAGE_CLASS, etc.). These are now configured in roxie-config.yaml or handled by roxie internally. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
90e8fc7 to
d8bfcf2
Compare
The legacy flow set CLUSTER=secured-cluster which was used as the cluster name in Central's cluster list and for CRS naming. Without this, roxie auto-generates random names like sensor-2595. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This reverts commit 94da706.
The legacy flow used CLUSTER=secured-cluster as the cluster name in Central's cluster list and for CRS naming. Pass it through to roxie via --set securedCluster.spec.clusterName rather than hardcoding in the config file. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>


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.yamlRemoved env vars
ROX_PRODUCT_BRANDINGRHACS_BRANDING--tagand knows RHACS brandingAPI_ENDPOINTlocalhost:8000--envrcSTORAGEpvcroxie-config.yaml:db.persistence.persistentVolumeClaim; hardcoded--set persistence.type=pvcin monitoringSTORAGE_CLASSfasterroxie-config.yaml:storageClassName: premium-rwoSTORAGE_SIZE"100"roxie-config.yaml:size: "100Gi"LOAD_BALANCERlbroxie-config.yaml:exposure.loadBalancer.enabled: trueMONITORING_LOAD_BALANCERnone--set exposure.type=nonein scriptSECURED_CLUSTER_AUTO_LOCK_PROCESS_BASELINES"true"sensor.shfor auto-lock baselinesroxie-config.yaml:processBaselines.autoLock: EnabledROX_TELEMETRY_STORAGE_KEY_V1R5fMy...b8uoWroxie-config.yaml: incustomize.envVarsROX_SCANNER_V4"true"roxie-config.yaml:scannerV4.scannerComponent: EnabledROX_NETFLOW_BATCHING"true"roxie-config.yaml: incustomize.envVarsROX_NETFLOW_CACHE_LIMITING"true"roxie-config.yaml: incustomize.envVarsSFA_AGENT"true"roxie-config.yaml:perNode.fileActivityMonitoring.mode: EnabledSENSOR_HELM_DEPLOY"true"ROX_DEPLOY_SENSOR_WITH_CRS"false"COMMON_DIR$STACKROX_DIR/deploy/commonSTACKROX_DIRused directly for monitoring chart pathTest 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