Skip to content
This repository was archived by the owner on Sep 9, 2026. It is now read-only.

NO_ISSUE: parallelize refresh-after-snapshot for faster boot - #164

Merged
openshift-merge-bot[bot] merged 1 commit into
osac-project:mainfrom
omer-vishlitzky:parallelize-refresh
May 26, 2026
Merged

openshift-merge-bot[bot] merged 1 commit into
osac-project:mainfrom
omer-vishlitzky:parallelize-refresh

Conversation

@omer-vishlitzky

@omer-vishlitzky omer-vishlitzky commented May 25, 2026

Copy link
Copy Markdown
Contributor

Summary

Parallelize the refresh-after-snapshot script to reduce boot time from ~10 minutes to ~2 minutes.

  • Phase 1: Keycloak sync + fulfillment credentials (parallel)
  • Phase 2: Kustomize apply
  • Phase 3: Fulfillment rollouts + AAP config + AAP controller wait (parallel, Keycloak sync continues in background)
  • Phase 4: prepare-aap + prepare-fulfillment
  • Phase 5: Restart fulfillment + tenant

Same logical steps, same error handling, just concurrent where dependencies allow.

Test plan

  • CI e2e-vmaas passes
  • Boot step completes in under 5 minutes (previously ~15 minutes)

Summary by CodeRabbit

  • Chores
    • Improved post-snapshot refresh: parallelized identity and credentials sync, staged readiness checks, and faster overall execution.
    • Added TLS/certificate stabilization and targeted service restarts to ensure updated CA/TLS mounts.
    • Introduced concurrent rollout and configuration steps with clearer per-step error reporting and blocking until critical credentials and services are ready.

Review Change Stack

@coderabbitai

coderabbitai Bot commented May 25, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@omer-vishlitzky, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 15 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository: osac-project/coderabbit/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Enterprise

Run ID: 4f4d8e6b-847f-4679-a151-cf6c9636a73b

📥 Commits

Reviewing files that changed from the base of the PR and between a27c9a2 and e012f36.

📒 Files selected for processing (1)
  • scripts/refresh-after-snapshot.sh

Walkthrough

The script refactors the post-snapshot refresh into callable functions and parallelizes Keycloak realm sync, fulfillment-credentials creation, kustomize overlay apply, TLS stabilization, fulfillment rollouts, and AAP configuration/readiness with coordinated waits. Security note: admin tokens and secrets are handled in background jobs—if uncaught failures occur, credential state could diverge (High severity; may leave services with stale/missing auth).

Changes

Refresh Workflow Parallelization

Layer / File(s) Summary
Keycloak realm synchronization function
scripts/refresh-after-snapshot.sh
keycloak_sync() hash-compares realm.json vs keycloak-realm ConfigMap, conditionally recreates the ConfigMap and restarts keycloak-service, polls Keycloak realm endpoint, obtains admin token, and upserts realm clients/users via the Keycloak admin REST API; optionally applies and waits for a password-setup Job.
Fulfillment controller credentials creation function
scripts/refresh-after-snapshot.sh
create_fulfillment_credentials() parses realm.json to find the service-account-enabled client and secret, errors if unresolved, deletes any existing fulfillment-controller-credentials secret in the installer namespace, and recreates it from derived values.
Background task startup and kustomize application
scripts/refresh-after-snapshot.sh
Starts keycloak_sync() and create_fulfillment_credentials() concurrently, blocks until credentials creation succeeds, deletes installer jobs, removes aap.yaml/job.yaml from base/osac-aap/config/base/kustomization.yaml, and applies overlays/${INSTALLER_KUSTOMIZE_OVERLAY}.
TLS certificate stabilization and deployment restart
scripts/refresh-after-snapshot.sh
Waits for multiple cert-manager Certificate resources to reach Ready, verifies success, then restarts selected fulfillment deployments to refresh TLS/CA mounts.
Fulfillment rollout monitoring function
scripts/refresh-after-snapshot.sh
wait_fulfillment_rollouts() runs oc rollout status for multiple fulfillment deployments in parallel, aggregates failures, and exits on error.
AAP configuration and controller readiness functions
scripts/refresh-after-snapshot.sh
apply_aap_configuration() exports installer vars and runs ./scripts/aap-configuration.sh; wait_aap_controller() polls for AutomationController Running and the AAP gateway API returning HTTP 200.
Concurrent execution and synchronization
scripts/refresh-after-snapshot.sh
Runs fulfillment rollouts, AAP configuration, and AAP readiness concurrently, awaits each with targeted error messages, waits for Keycloak sync completion, sets kubectl context namespace, and continues to final refresh steps.

Sequence Diagram(s)

Sequence diagrams are embedded in the hidden review stack artifact above for reference.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

Suggested labels

lgtm

Suggested reviewers

  • trewest
  • akshaynadkarni
  • tzumainn

Poem

🔁 Realm hashes checked and secrets remade in time,
Jobs hum in parallel, certificates climb,
Rollouts and controllers report back with a cheer,
Tokens and configs converge, the path now clear—
Refresh dances onward, concurrent and sublime.


Caution

Pre-merge checks failed

Please resolve all errors before merging. Addressing warnings is optional.

  • Ignore

❌ Failed checks (1 error, 2 warnings)

Check name Status Explanation Resolution
No-Injection-Vectors ❌ Error Script contains eval injection (lines 81, 205, 210) with unescaped Kubernetes API variables, plus jq filter injection (line 131) and JSON injection (line 37). Escape variables before eval: quote KC_URL/INSTALLER_NAMESPACE/AAP_ROUTE_HOST; use jq --arg for filter injection; escape JSON values. Avoid eval with external data.
Docstring Coverage ⚠️ Warning Docstring coverage is 40.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
Ai-Attribution ⚠️ Warning PR summary explicitly mentions "AI-generated summary" but commit message lacks required Red Hat AI attribution trailers (Assisted-by or Generated-by) per check requirements. Add Assisted-by: or Generated-by: trailer to commit message to document AI tool usage in accordance with Red Hat attribution guidelines.
✅ Passed checks (8 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately describes the main change: parallelizing the refresh-after-snapshot script to improve boot performance, which is the core objective of this PR.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
No-Hardcoded-Secrets ✅ Passed No new hardcoded secrets introduced. Pre-existing admin/admin Keycloak credentials remain unchanged from main. Other secrets sourced from realm.json file, not hardcoded.
No-Weak-Crypto ✅ Passed MD5 usage detected (lines 67-68) for ConfigMap change detection only, not security-sensitive operations. No other weak crypto patterns, custom implementations, or insecure token comparisons found.
Container-Privileges ✅ Passed PR only refactors shell script for parallelization; no container manifests with privileged: true, hostPID, hostNetwork, hostIPC, SYS_ADMIN, or allowPrivilegeEscalation found.
No-Sensitive-Data-In-Logs ✅ Passed Script properly protects sensitive data: no debug modes enabled, tokens/secrets never echoed to logs, all sensitive curl calls suppress output with >/dev/null.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@omer-vishlitzky
omer-vishlitzky force-pushed the parallelize-refresh branch 2 times, most recently from 5e90355 to 9ffa34b Compare May 25, 2026 15:57
@omer-vishlitzky omer-vishlitzky changed the title parallelize refresh-after-snapshot for faster boot NO_ISSUE: parallelize refresh-after-snapshot for faster boot May 25, 2026

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 `@scripts/refresh-after-snapshot.sh`:
- Around line 130-131: The current client selection uses serviceAccountsEnabled
and can return multiple clients; update the jq selectors so FC_CLIENT_ID and
FC_CLIENT_SECRET explicitly target the osac-controller client to match upstream
contract and README: use a jq filter that selects .clients[] | select(.clientId
== "osac-controller") to set FC_CLIENT_ID and then extract its .secret (or
empty) into FC_CLIENT_SECRET using REALM_JSON; ensure both assignments reference
the same explicit client-id "osac-controller" so multiple
service-account-enabled clients won't cause silent wrong selection.
- Around line 85-87: Replace hardcoded admin credentials by reading
KC_ADMIN_USER and KC_ADMIN_PASS from environment or a mounted secret file (fail
early if missing), then send them to Keycloak via curl using stdin (so
credentials are not visible in the process command line). Concretely: ensure
KC_ADMIN_USER/KC_ADMIN_PASS are loaded, validate they are non-empty, build the
form body (client_id=admin-cli&username=...&password=...&grant_type=password)
with printf or a heredoc and pipe it into curl using --data-binary `@-` (targeting
the same "${KC_URL}/realms/master/protocol/openid-connect/token") and capture
the access token into KC_ADMIN_TOKEN as before; keep the existing token
null/empty check and error out if retrieval fails.
🪄 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: osac-project/coderabbit/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Enterprise

Run ID: 307ec28e-a806-4d96-a7e4-9fae3d1f21d6

📥 Commits

Reviewing files that changed from the base of the PR and between dbea781 and 9ffa34b.

📒 Files selected for processing (1)
  • scripts/refresh-after-snapshot.sh

Comment thread scripts/refresh-after-snapshot.sh
Comment on lines +130 to +131
FC_CLIENT_ID=$(jq -er '.clients[] | select(.serviceAccountsEnabled == true) | .clientId' "${REALM_JSON}")
FC_CLIENT_SECRET=$(jq -er ".clients[] | select(.clientId == \"${FC_CLIENT_ID}\") | .secret // empty" "${REALM_JSON}")

@coderabbitai coderabbitai Bot May 25, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Correctness Risk (MEDIUM): Client selection logic differs from upstream contract.

The upstream scripts/setup.sh explicitly selects osac-controller:

FC_CLIENT_SECRET=$(jq -er '.clients[] | select(.clientId == "osac-controller") | .secret // empty' ...)

This implementation selects by serviceAccountsEnabled == true, which could match multiple clients. If multiple service-account-enabled clients exist in realm.json, jq outputs multiple lines and only the last clientId is captured—potentially selecting the wrong client silently.

The documented contract in overlays/osac-integration/README.md also specifies client-id=osac-controller.

🛡️ Proposed fix to match upstream contract
 create_fulfillment_credentials() {
     echo "[2/8] Recreating fulfillment controller credentials..."
-    FC_CLIENT_ID=$(jq -er '.clients[] | select(.serviceAccountsEnabled == true) | .clientId' "${REALM_JSON}")
-    FC_CLIENT_SECRET=$(jq -er ".clients[] | select(.clientId == \"${FC_CLIENT_ID}\") | .secret // empty" "${REALM_JSON}")
+    FC_CLIENT_ID="osac-controller"
+    FC_CLIENT_SECRET=$(jq -er '.clients[] | select(.clientId == "osac-controller") | .secret // empty' "${REALM_JSON}")
     [[ -n "${FC_CLIENT_SECRET}" ]] || { echo "ERROR: Could not resolve secret for ${FC_CLIENT_ID} in realm.json" >&2; exit 1; }
🤖 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 `@scripts/refresh-after-snapshot.sh` around lines 130 - 131, The current client
selection uses serviceAccountsEnabled and can return multiple clients; update
the jq selectors so FC_CLIENT_ID and FC_CLIENT_SECRET explicitly target the
osac-controller client to match upstream contract and README: use a jq filter
that selects .clients[] | select(.clientId == "osac-controller") to set
FC_CLIENT_ID and then extract its .secret (or empty) into FC_CLIENT_SECRET using
REALM_JSON; ensure both assignments reference the same explicit client-id
"osac-controller" so multiple service-account-enabled clients won't cause silent
wrong selection.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ci only, irrelevant

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Acknowledged — noted that create_fulfillment_credentials() in scripts/refresh-after-snapshot.sh is CI-only, so the multi-client selection risk via serviceAccountsEnabled == true is acceptable in that context.

(╯°□°)╯︵ 🐇


✏️ Learnings added
Learnt from: omer-vishlitzky
Repo: osac-project/osac-installer PR: 164
File: scripts/refresh-after-snapshot.sh:130-131
Timestamp: 2026-05-25T16:08:22.856Z
Learning: In `scripts/refresh-after-snapshot.sh` (osac-project/osac-installer), the `create_fulfillment_credentials()` function that selects the fulfillment client via `jq -er '.clients[] | select(.serviceAccountsEnabled == true)'` is used in CI only. The risk of it matching multiple service-account-enabled clients is considered acceptable and not a concern to flag in code review.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

@omer-vishlitzky

Copy link
Copy Markdown
Contributor Author

/retest

@omer-vishlitzky

Copy link
Copy Markdown
Contributor Author

/hold

@omer-vishlitzky

Copy link
Copy Markdown
Contributor Author

/retest

@openshift-ci openshift-ci Bot removed the lgtm label May 25, 2026

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 `@scripts/refresh-after-snapshot.sh`:
- Around line 105-118: The user upsert loop in scripts/refresh-after-snapshot.sh
silently ignores failures because the POST/PUT curl calls for each USER_JSON are
not checking HTTP response codes; modify the loop that iterates over
USER_JSON/USER_UUID so that after each curl PUT to
"${KC_URL}/admin/realms/osac/users/${USER_UUID}" and after each curl POST to
"${KC_URL}/admin/realms/osac/users" you capture the HTTP status (like
HTTP_CODE=$(curl -sk -o /dev/null -w "%{http_code}" ...)), validate it against
expected success codes (e.g., 200/204 for PUT, 201 for POST), and on non-success
log a clear error including USERNAME/USER_UUID/HTTP_CODE and either exit with a
non-zero status or collect failures and fail at the end; ensure you still print
the success messages ("Updated user" / "Created user") only when the response
indicates success.
- Around line 89-103: The PUT/POST curl invocations for syncing clients (code
handling CLIENT_JSON/CLIENT_UUID using KC_ADMIN_TOKEN and KC_URL) swallow
responses and always echo "Updated/Created client" even on 4xx/5xx; change the
upsert logic to capture HTTP status and response body from each curl (for both
the PUT to "${KC_URL}/admin/realms/osac/clients/${CLIENT_UUID}" and the POST to
"${KC_URL}/admin/realms/osac/clients"), check that the status code is a 2xx
before printing success, and on non-2xx log the status, response body and client
id (CID) and either retry or exit with non-zero to fail the script so
configuration errors aren’t silently ignored.
🪄 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: osac-project/coderabbit/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Enterprise

Run ID: f0ff268f-805c-4542-8df4-4d3df1830df4

📥 Commits

Reviewing files that changed from the base of the PR and between 9ffa34b and a27c9a2.

📒 Files selected for processing (1)
  • scripts/refresh-after-snapshot.sh

Comment on lines +89 to +103
echo " Syncing clients and users via admin API..."
jq -c '.clients[] | select(.protocol == "openid-connect" and .publicClient != true and .bearerOnly != true)' "${REALM_JSON}" | while IFS= read -r CLIENT_JSON; do
CID=$(echo "${CLIENT_JSON}" | jq -r '.clientId')
CLIENT_UUID=$(echo "${CLIENT_JSON}" | jq -r '.id')
HTTP_CODE=$(curl -sk -o /dev/null -w "%{http_code}" -H "Authorization: Bearer ${KC_ADMIN_TOKEN}" "${KC_URL}/admin/realms/osac/clients/${CLIENT_UUID}")
if [[ "${HTTP_CODE}" == "200" ]]; then
curl -sk -X PUT -H "Authorization: Bearer ${KC_ADMIN_TOKEN}" -H "Content-Type: application/json" \
"${KC_URL}/admin/realms/osac/clients/${CLIENT_UUID}" -d "${CLIENT_JSON}" >/dev/null
echo " Updated client: ${CID}"
else
curl -sk -X POST -H "Authorization: Bearer ${KC_ADMIN_TOKEN}" -H "Content-Type: application/json" \
"${KC_URL}/admin/realms/osac/clients" -d "${CLIENT_JSON}" >/dev/null
echo " Created client: ${CID}"
fi
done

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Reliability Risk (MEDIUM): Silent failure on client upsert operations.

The PUT/POST curl calls redirect output to /dev/null and don't validate HTTP response codes. If Keycloak returns a 4xx/5xx error, the script logs "Updated/Created client" anyway and continues, potentially leaving client configuration out of sync.

Impact: Downstream services may fail to authenticate if client sync silently fails.

🛡️ Proposed fix to validate upsert responses
         if [[ "${HTTP_CODE}" == "200" ]]; then
-            curl -sk -X PUT -H "Authorization: Bearer ${KC_ADMIN_TOKEN}" -H "Content-Type: application/json" \
-                "${KC_URL}/admin/realms/osac/clients/${CLIENT_UUID}" -d "${CLIENT_JSON}" >/dev/null
-            echo "  Updated client: ${CID}"
+            PUT_CODE=$(curl -sk -o /dev/null -w "%{http_code}" -X PUT -H "Authorization: Bearer ${KC_ADMIN_TOKEN}" -H "Content-Type: application/json" \
+                "${KC_URL}/admin/realms/osac/clients/${CLIENT_UUID}" -d "${CLIENT_JSON}")
+            [[ "${PUT_CODE}" =~ ^2 ]] || { echo "ERROR: Failed to update client ${CID} (HTTP ${PUT_CODE})" >&2; exit 1; }
+            echo "  Updated client: ${CID}"
         else
-            curl -sk -X POST -H "Authorization: Bearer ${KC_ADMIN_TOKEN}" -H "Content-Type: application/json" \
-                "${KC_URL}/admin/realms/osac/clients" -d "${CLIENT_JSON}" >/dev/null
+            POST_CODE=$(curl -sk -o /dev/null -w "%{http_code}" -X POST -H "Authorization: Bearer ${KC_ADMIN_TOKEN}" -H "Content-Type: application/json" \
+                "${KC_URL}/admin/realms/osac/clients" -d "${CLIENT_JSON}")
+            [[ "${POST_CODE}" =~ ^2 ]] || { echo "ERROR: Failed to create client ${CID} (HTTP ${POST_CODE})" >&2; exit 1; }
             echo "  Created client: ${CID}"
         fi
🤖 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 `@scripts/refresh-after-snapshot.sh` around lines 89 - 103, The PUT/POST curl
invocations for syncing clients (code handling CLIENT_JSON/CLIENT_UUID using
KC_ADMIN_TOKEN and KC_URL) swallow responses and always echo "Updated/Created
client" even on 4xx/5xx; change the upsert logic to capture HTTP status and
response body from each curl (for both the PUT to
"${KC_URL}/admin/realms/osac/clients/${CLIENT_UUID}" and the POST to
"${KC_URL}/admin/realms/osac/clients"), check that the status code is a 2xx
before printing success, and on non-2xx log the status, response body and client
id (CID) and either retry or exit with non-zero to fail the script so
configuration errors aren’t silently ignored.

Comment on lines +105 to +118
jq -c '.users[]?' "${REALM_JSON}" | while IFS= read -r USER_JSON; do
USERNAME=$(echo "${USER_JSON}" | jq -r '.username')
USER_UUID=$(echo "${USER_JSON}" | jq -r '.id')
HTTP_CODE=$(curl -sk -o /dev/null -w "%{http_code}" -H "Authorization: Bearer ${KC_ADMIN_TOKEN}" "${KC_URL}/admin/realms/osac/users/${USER_UUID}")
if [[ "${HTTP_CODE}" == "200" ]]; then
curl -sk -X PUT -H "Authorization: Bearer ${KC_ADMIN_TOKEN}" -H "Content-Type: application/json" \
"${KC_URL}/admin/realms/osac/users/${USER_UUID}" -d "${USER_JSON}" >/dev/null
echo " Updated user: ${USERNAME}"
else
curl -sk -X POST -H "Authorization: Bearer ${KC_ADMIN_TOKEN}" -H "Content-Type: application/json" \
"${KC_URL}/admin/realms/osac/users" -d "${USER_JSON}" >/dev/null
echo " Created user: ${USERNAME}"
fi
done

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Reliability Risk (MEDIUM): Silent failure on user upsert operations.

Same issue as client sync above—PUT/POST calls don't validate HTTP status codes. Failed user syncs could leave user state inconsistent, affecting login or authorization flows.

Apply the same response-code validation pattern as recommended for client upserts.

🤖 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 `@scripts/refresh-after-snapshot.sh` around lines 105 - 118, The user upsert
loop in scripts/refresh-after-snapshot.sh silently ignores failures because the
POST/PUT curl calls for each USER_JSON are not checking HTTP response codes;
modify the loop that iterates over USER_JSON/USER_UUID so that after each curl
PUT to "${KC_URL}/admin/realms/osac/users/${USER_UUID}" and after each curl POST
to "${KC_URL}/admin/realms/osac/users" you capture the HTTP status (like
HTTP_CODE=$(curl -sk -o /dev/null -w "%{http_code}" ...)), validate it against
expected success codes (e.g., 200/204 for PUT, 201 for POST), and on non-success
log a clear error including USERNAME/USER_UUID/HTTP_CODE and either exit with a
non-zero status or collect failures and fail at the end; ensure you still print
the success messages ("Updated user" / "Created user") only when the response
indicates success.

@omer-vishlitzky

Copy link
Copy Markdown
Contributor Author

/hold

@openshift-ci

openshift-ci Bot commented May 26, 2026

Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: danmanor, jhernand, omer-vishlitzky

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:
  • OWNERS [danmanor,jhernand,omer-vishlitzky]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@omer-vishlitzky

Copy link
Copy Markdown
Contributor Author

/unhold

@openshift-merge-bot
openshift-merge-bot Bot merged commit 0e2bc3f into osac-project:main May 26, 2026
9 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants