CNTRLPLANE-3222: Add e2e-azure-v2-self-managed CI job for HyperShift - #77674
Merged
openshift-merge-bot[bot] merged 1 commit intoMay 8, 2026
Merged
Conversation
openshift-ci
Bot
added
approved
Member
Author
|
Closing - this incorrectly used the AKS (managed Azure) infrastructure. Self-managed Azure CI workflow changes will be done separately using the correct |
openshift-merge-bot
Bot
added
the
rehearsals-ack
bryan-cox
force-pushed
the
CNTRLPLANE-3222
branch
2 times, most recently
from
April 13, 2026 14:00
f6621fa to
b8ebd76
Compare
Contributor
|
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 an optional Azure self‑managed HyperShift e2e test and presubmit, plus new step‑registry chains/workflows to create three self‑managed guest clusters, run v2 e2e tests against each, and destroy the guests; includes OWNERS and metadata for new directories. Changes
Sequence Diagram(s)sequenceDiagram
rect rgba(0,128,255,0.5)
participant Prow as Prow/ci-operator
end
rect rgba(0,200,0,0.5)
participant Workflow as Step Registry Workflow
end
rect rgba(255,128,0,0.5)
participant Hypershift as Hypershift CLI
end
rect rgba(255,0,128,0.5)
participant Azure as Azure API
end
rect rgba(128,0,255,0.5)
participant Guests as Guest Clusters
end
Prow->>Workflow: trigger workflow (pre → test → post)
Workflow->>Hypershift: run "hypershift create cluster azure" x3
Hypershift->>Azure: provision resources
Azure-->>Guests: create guest clusters
Guests-->>Hypershift: report Available status & kubeconfigs
Hypershift-->>Workflow: return kubeconfigs and names
Workflow->>Workflow: run e2e tests per cluster using kubeconfigs
Workflow->>Hypershift: run "hypershift destroy cluster azure" x3
Hypershift->>Azure: delete resources
Azure-->>Workflow: deletion complete
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes 🚥 Pre-merge checks | ✅ 10✅ Passed checks (10 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
openshift-merge-bot
Bot
removed
the
rehearsals-ack
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yaml (1)
113-120: Consider capturing and checking exit codes from parallel cluster creation.The current
waitcalls don't capture exit codes from the parallel create commands. If anyhypershift create clustercommand fails, the script continues and may fail later with a less clear error when waiting for cluster availability.Proposed improvement
# Wait for create commands to complete echo "$(date) Waiting for cluster create commands to finish..." - wait ${PUBLIC_PID} + wait ${PUBLIC_PID} || { echo "ERROR: Public cluster create failed"; exit 1; } echo "$(date) Public cluster create command completed" - wait ${PRIVATE_PID} + wait ${PRIVATE_PID} || { echo "ERROR: Private cluster create failed"; exit 1; } echo "$(date) Private cluster create command completed" - wait ${OAUTH_LB_PID} + wait ${OAUTH_LB_PID} || { echo "ERROR: OAuth LB cluster create failed"; exit 1; } echo "$(date) OAuth LB cluster create command completed"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yaml` around lines 113 - 120, The script uses wait on background PIDs (PUBLIC_PID, PRIVATE_PID, OAUTH_LB_PID) but doesn't capture their exit statuses, so failures from the underlying hypershift create commands are ignored; update the block that waits for each PID to capture and check the exit code for each wait (e.g., wait <PID> and then check $? or capture the wait return into a variable), and if any exit code is non-zero emit an error message with the PID/cluster context and exit the script with a non-zero status to fail fast; apply this change around the existing wait lines for PUBLIC_PID, PRIVATE_PID and OAUTH_LB_PID and ensure meaningful logging for each failure.ci-operator/step-registry/hypershift/azure/e2e/v2-self-managed/hypershift-azure-e2e-v2-self-managed-workflow.yaml (1)
1-39: Workflow structure is correct - minor naming observation.The workflow correctly orchestrates the pre/test/post phases and all referenced chains exist. The post phase properly handles cleanup with
best_effortsemantics via the destroy chains.One observation:
HYPERSHIFT_EXTERNAL_DNS_DOMAINusesaks-e2e.hypershift.azure.devcluster.openshift.comwhich contains "aks" in the subdomain. Since this is a self-managed Azure workflow, this naming could be confusing. Per the PR comment from the author, this PR is being closed because it "incorrectly used AKS (managed Azure) infrastructure" - this domain reference might be part of that concern.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ci-operator/step-registry/hypershift/azure/e2e/v2-self-managed/hypershift-azure-e2e-v2-self-managed-workflow.yaml` around lines 1 - 39, The HYPERSHIFT_EXTERNAL_DNS_DOMAIN env var contains the substring "aks" which wrongly implies AKS (managed Azure); update the workflow (workflow as: hypershift-azure-e2e-v2-self-managed) to use a self-managed-appropriate DNS name by changing HYPERSHIFT_EXTERNAL_DNS_DOMAIN to a non-AKS domain (e.g., replace "aks-e2e" with "hypershift-azure-selfmanaged-e2e" or similar) in the env block so the name correctly reflects self-managed Azure infrastructure.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yaml`:
- Around line 136-141: The loop that creates kubeconfigs uses a relative binary
path "bin/hypershift" which is inconsistent with other uses of
"/usr/bin/hypershift" and may fail; update the command inside the for loop (the
call that currently reads bin/hypershift create kubeconfig --namespace=clusters
--name="${CLUSTER}") to use the absolute path /usr/bin/hypershift so it matches
the other invocations and the binary provided by the hypershift-operator image,
keeping the rest of the loop (variables PUBLIC_NAME, PRIVATE_NAME,
OAUTH_LB_NAME, and KUBECONFIG handling) unchanged.
In
`@ci-operator/step-registry/hypershift/azure/destroy-selfmanaged-guests/hypershift-azure-destroy-selfmanaged-guests-chain.yaml`:
- Around line 25-34: The current loop over CLUSTER calling bin/hypershift
destroy cluster azure uses "|| echo" which swallows failures; modify the loop
that iterates over "${PUBLIC_NAME}" "${PRIVATE_NAME}" "${OAUTH_LB_NAME}" to
record each destroy exit status (invoke bin/hypershift destroy cluster azure
with its args as-is), set a local failure flag (e.g., DESTROY_FAILED=1) when a
non-zero exit code occurs while still continuing to the next CLUSTER, and after
the for-loop check that flag and exit non-zero if any destroy failed so the step
surfaces leaked resources while preserving best_effort-style continuation.
---
Nitpick comments:
In
`@ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yaml`:
- Around line 113-120: The script uses wait on background PIDs (PUBLIC_PID,
PRIVATE_PID, OAUTH_LB_PID) but doesn't capture their exit statuses, so failures
from the underlying hypershift create commands are ignored; update the block
that waits for each PID to capture and check the exit code for each wait (e.g.,
wait <PID> and then check $? or capture the wait return into a variable), and if
any exit code is non-zero emit an error message with the PID/cluster context and
exit the script with a non-zero status to fail fast; apply this change around
the existing wait lines for PUBLIC_PID, PRIVATE_PID and OAUTH_LB_PID and ensure
meaningful logging for each failure.
In
`@ci-operator/step-registry/hypershift/azure/e2e/v2-self-managed/hypershift-azure-e2e-v2-self-managed-workflow.yaml`:
- Around line 1-39: The HYPERSHIFT_EXTERNAL_DNS_DOMAIN env var contains the
substring "aks" which wrongly implies AKS (managed Azure); update the workflow
(workflow as: hypershift-azure-e2e-v2-self-managed) to use a
self-managed-appropriate DNS name by changing HYPERSHIFT_EXTERNAL_DNS_DOMAIN to
a non-AKS domain (e.g., replace "aks-e2e" with
"hypershift-azure-selfmanaged-e2e" or similar) in the env block so the name
correctly reflects self-managed Azure infrastructure.
🪄 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: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: d0bc2bf6-be12-4b4a-ac99-1e677b0b7bc2
📒 Files selected for processing (14)
ci-operator/config/openshift/hypershift/openshift-hypershift-main.yamlci-operator/jobs/openshift/hypershift/openshift-hypershift-main-presubmits.yamlci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/OWNERSci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.metadata.jsonci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yamlci-operator/step-registry/hypershift/azure/destroy-selfmanaged-guests/OWNERSci-operator/step-registry/hypershift/azure/destroy-selfmanaged-guests/hypershift-azure-destroy-selfmanaged-guests-chain.metadata.jsonci-operator/step-registry/hypershift/azure/destroy-selfmanaged-guests/hypershift-azure-destroy-selfmanaged-guests-chain.yamlci-operator/step-registry/hypershift/azure/e2e/v2-self-managed/OWNERSci-operator/step-registry/hypershift/azure/e2e/v2-self-managed/hypershift-azure-e2e-v2-self-managed-workflow.metadata.jsonci-operator/step-registry/hypershift/azure/e2e/v2-self-managed/hypershift-azure-e2e-v2-self-managed-workflow.yamlci-operator/step-registry/hypershift/azure/run-e2e-v2-selfmanaged/OWNERSci-operator/step-registry/hypershift/azure/run-e2e-v2-selfmanaged/hypershift-azure-run-e2e-v2-selfmanaged-chain.metadata.jsonci-operator/step-registry/hypershift/azure/run-e2e-v2-selfmanaged/hypershift-azure-run-e2e-v2-selfmanaged-chain.yaml
bryan-cox
force-pushed
the
CNTRLPLANE-3222
branch
from
April 13, 2026 14:06
b8ebd76 to
f2bf419
Compare
openshift-ci
Bot
removed
the
do-not-merge/invalid-owners-file
Contributor
There was a problem hiding this comment.
♻️ Duplicate comments (1)
ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yaml (1)
136-141:⚠️ Potential issue | 🟡 MinorPath inconsistency:
bin/hypershiftvs/usr/bin/hypershift.Line 138 uses relative path
bin/hypershiftwhile lines 87, 98, and 107 use absolute path/usr/bin/hypershift. Thefrom: hypershift-operatorimage provides the binary at/usr/bin/hypershift.,
Proposed fix
for CLUSTER in "${PUBLIC_NAME}" "${PRIVATE_NAME}" "${OAUTH_LB_NAME}"; do echo "$(date) Creating kubeconfig for ${CLUSTER}" - bin/hypershift create kubeconfig --namespace=clusters --name="${CLUSTER}" > "${SHARED_DIR}/nested_kubeconfig_${CLUSTER}" + /usr/bin/hypershift create kubeconfig --namespace=clusters --name="${CLUSTER}" > "${SHARED_DIR}/nested_kubeconfig_${CLUSTER}" echo "$(date) Waiting for clusteroperators on ${CLUSTER}..." KUBECONFIG="${SHARED_DIR}/nested_kubeconfig_${CLUSTER}" oc wait clusterversion/version --for='condition=Available=True' --timeout=30m || true done🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yaml` around lines 136 - 141, The script is inconsistently invoking the hypershift binary with a relative path `bin/hypershift`; update the loop that creates kubeconfigs (the for CLUSTER in ... block that echoes "Creating kubeconfig for ${CLUSTER}" and calls `bin/hypershift create kubeconfig`) to use the absolute binary path `/usr/bin/hypershift` to match the other invocations (and the hypershift-operator image); ensure the command shown as `bin/hypershift create kubeconfig --namespace=clusters --name="${CLUSTER}"` is replaced with `/usr/bin/hypershift create kubeconfig --namespace=clusters --name="${CLUSTER}"`.
🧹 Nitpick comments (2)
ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yaml (2)
139-141: Consider logging clusterversion wait failures instead of silently ignoring.The
|| truesuppresses failures from the clusterversion wait. While the primary hosted cluster availability is verified earlier (lines 124-133), silently ignoring this secondary check could mask node-level issues.Suggested improvement
echo "$(date) Waiting for clusteroperators on ${CLUSTER}..." - KUBECONFIG="${SHARED_DIR}/nested_kubeconfig_${CLUSTER}" oc wait clusterversion/version --for='condition=Available=True' --timeout=30m || true + KUBECONFIG="${SHARED_DIR}/nested_kubeconfig_${CLUSTER}" oc wait clusterversion/version --for='condition=Available=True' --timeout=30m || echo "$(date) WARNING: clusterversion wait timed out for ${CLUSTER}, continuing anyway" done🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yaml` around lines 139 - 141, The clusterversion wait currently swallows failures with "|| true"; change it to capture the command exit status and log a timestamped error when the wait fails instead of silently ignoring it: run KUBECONFIG="${SHARED_DIR}/nested_kubeconfig_${CLUSTER}" oc wait clusterversion/version --for='condition=Available=True' --timeout=30m, check its return code ($?), and if non-zero emit a clear echo/error line including the cluster name and the failure status (and optionally the oc output) so failures are visible while still allowing the script to proceed if you choose; update the occurrence referencing KUBECONFIG and the oc wait command and remove the trailing "|| true".
113-120: Parallel wait could leave orphan processes on early failure.With
set -eenabled, ifwait ${PUBLIC_PID}fails, the script exits without waiting for the other PIDs. Those background processes will continue running until the CI job terminates. Consider waiting for all processes together or adding trap-based cleanup.Alternative: wait for all processes and aggregate failures
# Wait for create commands to complete echo "$(date) Waiting for cluster create commands to finish..." - wait ${PUBLIC_PID} - echo "$(date) Public cluster create command completed" - wait ${PRIVATE_PID} - echo "$(date) Private cluster create command completed" - wait ${OAUTH_LB_PID} - echo "$(date) OAuth LB cluster create command completed" + FAILED=0 + wait ${PUBLIC_PID} || FAILED=1 + echo "$(date) Public cluster create command completed (exit: $?)" + wait ${PRIVATE_PID} || FAILED=1 + echo "$(date) Private cluster create command completed (exit: $?)" + wait ${OAUTH_LB_PID} || FAILED=1 + echo "$(date) OAuth LB cluster create command completed (exit: $?)" + if [[ ${FAILED} -ne 0 ]]; then + echo "$(date) One or more cluster create commands failed" + exit 1 + fi🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yaml` around lines 113 - 120, The sequential waits on PUBLIC_PID, PRIVATE_PID and OAUTH_LB_PID can cause orphaned background processes if one wait fails under set -e; update the block that currently calls wait ${PUBLIC_PID}, wait ${PRIVATE_PID}, wait ${OAUTH_LB_PID} (and the surrounding create commands) to instead wait for all three PIDs without exiting on the first failure—e.g., capture each wait's exit status (use wait || true for PUBLIC_PID, PRIVATE_PID and OAUTH_LB_PID), aggregate those statuses and then exit non-zero if any failed; optionally add a trap that kills remaining background PIDs on early termination to ensure cleanup.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In
`@ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yaml`:
- Around line 136-141: The script is inconsistently invoking the hypershift
binary with a relative path `bin/hypershift`; update the loop that creates
kubeconfigs (the for CLUSTER in ... block that echoes "Creating kubeconfig for
${CLUSTER}" and calls `bin/hypershift create kubeconfig`) to use the absolute
binary path `/usr/bin/hypershift` to match the other invocations (and the
hypershift-operator image); ensure the command shown as `bin/hypershift create
kubeconfig --namespace=clusters --name="${CLUSTER}"` is replaced with
`/usr/bin/hypershift create kubeconfig --namespace=clusters
--name="${CLUSTER}"`.
---
Nitpick comments:
In
`@ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yaml`:
- Around line 139-141: The clusterversion wait currently swallows failures with
"|| true"; change it to capture the command exit status and log a timestamped
error when the wait fails instead of silently ignoring it: run
KUBECONFIG="${SHARED_DIR}/nested_kubeconfig_${CLUSTER}" oc wait
clusterversion/version --for='condition=Available=True' --timeout=30m, check its
return code ($?), and if non-zero emit a clear echo/error line including the
cluster name and the failure status (and optionally the oc output) so failures
are visible while still allowing the script to proceed if you choose; update the
occurrence referencing KUBECONFIG and the oc wait command and remove the
trailing "|| true".
- Around line 113-120: The sequential waits on PUBLIC_PID, PRIVATE_PID and
OAUTH_LB_PID can cause orphaned background processes if one wait fails under set
-e; update the block that currently calls wait ${PUBLIC_PID}, wait
${PRIVATE_PID}, wait ${OAUTH_LB_PID} (and the surrounding create commands) to
instead wait for all three PIDs without exiting on the first failure—e.g.,
capture each wait's exit status (use wait || true for PUBLIC_PID, PRIVATE_PID
and OAUTH_LB_PID), aggregate those statuses and then exit non-zero if any
failed; optionally add a trap that kills remaining background PIDs on early
termination to ensure cleanup.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: d1baacfc-d923-4320-af13-f92d8d14b0c9
📒 Files selected for processing (14)
ci-operator/config/openshift/hypershift/openshift-hypershift-main.yamlci-operator/jobs/openshift/hypershift/openshift-hypershift-main-presubmits.yamlci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/OWNERSci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.metadata.jsonci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yamlci-operator/step-registry/hypershift/azure/destroy-selfmanaged-guests/OWNERSci-operator/step-registry/hypershift/azure/destroy-selfmanaged-guests/hypershift-azure-destroy-selfmanaged-guests-chain.metadata.jsonci-operator/step-registry/hypershift/azure/destroy-selfmanaged-guests/hypershift-azure-destroy-selfmanaged-guests-chain.yamlci-operator/step-registry/hypershift/azure/e2e/v2-self-managed/OWNERSci-operator/step-registry/hypershift/azure/e2e/v2-self-managed/hypershift-azure-e2e-v2-self-managed-workflow.metadata.jsonci-operator/step-registry/hypershift/azure/e2e/v2-self-managed/hypershift-azure-e2e-v2-self-managed-workflow.yamlci-operator/step-registry/hypershift/azure/run-e2e-v2-selfmanaged/OWNERSci-operator/step-registry/hypershift/azure/run-e2e-v2-selfmanaged/hypershift-azure-run-e2e-v2-selfmanaged-chain.metadata.jsonci-operator/step-registry/hypershift/azure/run-e2e-v2-selfmanaged/hypershift-azure-run-e2e-v2-selfmanaged-chain.yaml
✅ Files skipped from review due to trivial changes (10)
- ci-operator/step-registry/hypershift/azure/destroy-selfmanaged-guests/OWNERS
- ci-operator/step-registry/hypershift/azure/run-e2e-v2-selfmanaged/hypershift-azure-run-e2e-v2-selfmanaged-chain.metadata.json
- ci-operator/step-registry/hypershift/azure/run-e2e-v2-selfmanaged/OWNERS
- ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/OWNERS
- ci-operator/step-registry/hypershift/azure/e2e/v2-self-managed/hypershift-azure-e2e-v2-self-managed-workflow.metadata.json
- ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.metadata.json
- ci-operator/step-registry/hypershift/azure/destroy-selfmanaged-guests/hypershift-azure-destroy-selfmanaged-guests-chain.metadata.json
- ci-operator/step-registry/hypershift/azure/e2e/v2-self-managed/OWNERS
- ci-operator/jobs/openshift/hypershift/openshift-hypershift-main-presubmits.yaml
- ci-operator/step-registry/hypershift/azure/e2e/v2-self-managed/hypershift-azure-e2e-v2-self-managed-workflow.yaml
🚧 Files skipped from review as they are similar to previous changes (2)
- ci-operator/step-registry/hypershift/azure/run-e2e-v2-selfmanaged/hypershift-azure-run-e2e-v2-selfmanaged-chain.yaml
- ci-operator/step-registry/hypershift/azure/destroy-selfmanaged-guests/hypershift-azure-destroy-selfmanaged-guests-chain.yaml
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yaml (1)
129-137: Use the management cluster namespace from${SHARED_DIR}instead of hardcodingclusters.Hardcoding
--namespace=clustersmakes this chain brittle if the nested management workflow uses a non-default namespace.Proposed refactor
# Use the nested management cluster kubeconfig export KUBECONFIG="${SHARED_DIR}/management_cluster_kubeconfig" + HYPERSHIFT_NAMESPACE="clusters" + if [[ -f "${SHARED_DIR}/management_cluster_namespace" ]]; then + HYPERSHIFT_NAMESPACE="$(cat "${SHARED_DIR}/management_cluster_namespace")" + fi @@ - oc wait --timeout=30m --for=condition=Available --namespace=clusters "hostedcluster/${PUBLIC_NAME}" + oc wait --timeout=30m --for=condition=Available --namespace="${HYPERSHIFT_NAMESPACE}" "hostedcluster/${PUBLIC_NAME}" @@ - oc wait --timeout=30m --for=condition=Available --namespace=clusters "hostedcluster/${PRIVATE_NAME}" + oc wait --timeout=30m --for=condition=Available --namespace="${HYPERSHIFT_NAMESPACE}" "hostedcluster/${PRIVATE_NAME}" @@ - oc wait --timeout=30m --for=condition=Available --namespace=clusters "hostedcluster/${OAUTH_LB_NAME}" + oc wait --timeout=30m --for=condition=Available --namespace="${HYPERSHIFT_NAMESPACE}" "hostedcluster/${OAUTH_LB_NAME}" @@ - /usr/bin/hypershift create kubeconfig --namespace=clusters --name="${CLUSTER}" > "${SHARED_DIR}/nested_kubeconfig_${CLUSTER}" + /usr/bin/hypershift create kubeconfig --namespace="${HYPERSHIFT_NAMESPACE}" --name="${CLUSTER}" > "${SHARED_DIR}/nested_kubeconfig_${CLUSTER}"Also applies to: 143-143
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yaml` around lines 129 - 137, Replace the hardcoded --namespace=clusters in the oc wait commands with a variable taken from the shared-dir management namespace file: read MANAGEMENT_CLUSTER_NAMESPACE from "${SHARED_DIR}/management_cluster_namespace" (or similar file placed into SHARED_DIR) before the oc wait calls, defaulting to "clusters" if the file is empty; then use --namespace="${MANAGEMENT_CLUSTER_NAMESPACE}" for the oc wait invocations that reference PUBLIC_NAME, PRIVATE_NAME and OAUTH_LB_NAME so the chain honors nested-management workflows.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yaml`:
- Around line 127-160: The step's timeout: 60m0s is too short given the
sequential oc wait calls (three initial oc wait commands and three
clusterversion waits inside the for loop) which can sum to multiple 30m
intervals; update the step's timeout field (timeout:) in this YAML to a much
larger value (e.g. 240m0s or at least 180m0s) so the job can complete the
sequential oc wait and clusterversion waits (references: the three oc wait
--for=condition=Available lines and the
KUBECONFIG="${SHARED_DIR}/nested_kubeconfig_${CLUSTER}" oc wait
clusterversion/version --for='condition=Available=True' --timeout=30m loop).
---
Nitpick comments:
In
`@ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yaml`:
- Around line 129-137: Replace the hardcoded --namespace=clusters in the oc wait
commands with a variable taken from the shared-dir management namespace file:
read MANAGEMENT_CLUSTER_NAMESPACE from
"${SHARED_DIR}/management_cluster_namespace" (or similar file placed into
SHARED_DIR) before the oc wait calls, defaulting to "clusters" if the file is
empty; then use --namespace="${MANAGEMENT_CLUSTER_NAMESPACE}" for the oc wait
invocations that reference PUBLIC_NAME, PRIVATE_NAME and OAUTH_LB_NAME so the
chain honors nested-management workflows.
🪄 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: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 722cdcd2-01e5-40d0-a757-552e88860182
📒 Files selected for processing (1)
ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yaml
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yaml (1)
127-160:⚠️ Potential issue | 🟠 Major
timeout: 120m0sis still below this step's explicit wait budget.This is closer than the earlier 60m value, but the script still serializes three 30m
HostedClusterwaits and three additional 30m guestclusterversion/versionwaits. That is 180m of readiness time before accounting for the create commands themselves, so the step can still time out while following its normal worst-case path.💡 Proposed fix
- timeout: 120m0s + timeout: 240m0s🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yaml` around lines 127 - 160, The step's overall timeout (timeout: 120m0s) is too short because the script can serially wait up to 180m (three 30m oc wait for HostedCluster plus three 30m clusterversion waits); increase the step timeout to exceed the worst-case sum of waits (plus buffer for create commands), e.g. set timeout to at least 200-220m; update the timeout value referenced as "timeout: 120m0s" in the YAML and ensure any CI timeout metadata for this step is adjusted so the oc wait lines (the three oc wait --for=condition=Available --timeout=30m lines and the KUBECONFIG ... oc wait clusterversion/version --for='condition=Available=True' --timeout=30m) can complete without the step being killed.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yaml`:
- Around line 50-54: The script currently silently omits the private-link flag
when ${SHARED_DIR}/azure_private_nat_subnet_id is missing; change the logic that
sets AZURE_PRIVATE_NAT_SUBNET_ID (and the duplicate block around the 93-96
region) to treat the subnet file as a hard prerequisite: if the file does not
exist or yields an empty value, emit an error message and exit non‑zero instead
of continuing. Locate the blocks referencing AZURE_PRIVATE_NAT_SUBNET_ID and
${SHARED_DIR}/azure_private_nat_subnet_id and replace the permissive if-check
with one that validates presence/non-empty content and fails fast so the job
fails when the private NAT subnet is missing.
- Around line 140-145: The current loop that waits for clusterversion uses "oc
wait clusterversion/version --for='condition=Available=True' --timeout=30m" and
swallows failures by echoing a WARNING; change this so the step fails if any of
the clusters in "${PUBLIC_NAME}" "${PRIVATE_NAME}" "${OAUTH_LB_NAME}" do not
reach Available within the timeout: after creating the kubeconfig file named
"${SHARED_DIR}/nested_kubeconfig_${CLUSTER}" run the oc wait command and on
non-zero exit return a non-zero exit code (or call exit 1) with a clear error
log mentioning the cluster name, ensuring the provisioning failure isn’t
converted to a warning and the job halts instead of proceeding to e2e.
---
Duplicate comments:
In
`@ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yaml`:
- Around line 127-160: The step's overall timeout (timeout: 120m0s) is too short
because the script can serially wait up to 180m (three 30m oc wait for
HostedCluster plus three 30m clusterversion waits); increase the step timeout to
exceed the worst-case sum of waits (plus buffer for create commands), e.g. set
timeout to at least 200-220m; update the timeout value referenced as "timeout:
120m0s" in the YAML and ensure any CI timeout metadata for this step is adjusted
so the oc wait lines (the three oc wait --for=condition=Available --timeout=30m
lines and the KUBECONFIG ... oc wait clusterversion/version
--for='condition=Available=True' --timeout=30m) can complete without the step
being killed.
🪄 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: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 794bf66c-f51b-4bb0-99c7-29e3bdac93e5
📒 Files selected for processing (1)
ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yaml
Contributor
There was a problem hiding this comment.
♻️ Duplicate comments (1)
ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yaml (1)
125-165:⚠️ Potential issue | 🟠 Major
timeout: 120m0sis still below the scripted worst case.This step can spend up to 90 minutes in the three hostedcluster waits plus another 90 minutes in the three
clusterversionwaits, all sequentially, before counting any time spent inside the create commands. A 120-minute cap will still terminate slow-but-healthy runs.Proposed fix
- timeout: 120m0s + timeout: 240m0s🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yaml` around lines 125 - 165, The step's timeout field currently set as "timeout: 120m0s" is too short for the worst-case sequential waits; update the timeout value to a sufficiently larger duration (e.g., "timeout: 240m0s") so the three oc wait hostedcluster calls and three clusterversion waits plus create time can complete; locate the timeout entry (the existing "timeout: 120m0s") in the hypershift-azure-create-selfmanaged-guests-chain step and replace it with the new value.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In
`@ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yaml`:
- Around line 125-165: The step's timeout field currently set as "timeout:
120m0s" is too short for the worst-case sequential waits; update the timeout
value to a sufficiently larger duration (e.g., "timeout: 240m0s") so the three
oc wait hostedcluster calls and three clusterversion waits plus create time can
complete; locate the timeout entry (the existing "timeout: 120m0s") in the
hypershift-azure-create-selfmanaged-guests-chain step and replace it with the
new value.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: c0d6eb1b-b145-425c-92ca-296380967647
📒 Files selected for processing (1)
ci-operator/step-registry/hypershift/azure/create-selfmanaged-guests/hypershift-azure-create-selfmanaged-guests-chain.yaml
Member
Author
|
/pj-rehearse pull-ci-openshift-hypershift-main-e2e-azure-v2-self-managed |
Contributor
|
@bryan-cox: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
Member
Author
|
/pj-rehearse pull-ci-openshift-hypershift-main-e2e-azure-v2-self-managed |
Contributor
|
@bryan-cox: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
Member
Author
|
/pj-rehearse pull-ci-openshift-hypershift-main-e2e-azure-v2-self-managed |
Contributor
|
@bryan-cox: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
Member
Author
|
/test rehearse-77674-pull-ci-openshift-hypershift-main-e2e-azure-v2-self-managed |
Member
Author
|
/pj-rehearse pull-ci-openshift-hypershift-main-e2e-azure-v2-self-managed |
Contributor
|
@bryan-cox: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
Member
Author
|
/pj-rehearse pull-ci-openshift-hypershift-main-e2e-azure-v2-self-managed |
Contributor
|
@bryan-cox: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
Contributor
|
@hector-vido: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
Member
Author
|
/pj-rehearse pull-ci-openshift-hypershift-main-e2e-azure-v2-self-managed |
Contributor
|
@bryan-cox: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
Member
Author
|
/pj-rehearse pull-ci-openshift-hypershift-main-e2e-azure-self-managed |
Contributor
|
@bryan-cox: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
Member
Author
|
/pj-rehearse pull-ci-openshift-hypershift-main-e2e-azure-self-managed |
Contributor
|
@bryan-cox: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
Member
Author
|
/pj-rehearse pull-ci-openshift-hypershift-main-e2e-azure-self-managed |
Contributor
|
@bryan-cox: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
Member
Author
|
/pj-rehearse pull-ci-openshift-hypershift-main-e2e-azure-self-managed |
Contributor
|
@bryan-cox: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
Member
Author
|
/pj-rehearse pull-ci-openshift-hypershift-main-e2e-azure-self-managed |
Contributor
|
@bryan-cox: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
Contributor
|
/lgtm |
Member
Author
|
/pj-rehearse ack |
Contributor
|
@bryan-cox: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
openshift-merge-bot
Bot
added
the
rehearsals-ack
Contributor
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bryan-cox, csrwng The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Contributor
|
@bryan-cox: 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. |
4 tasks
mhanss
pushed a commit
to mhanss/release
that referenced
this pull request
May 26, 2026
…t#77674) Adds a new hypershift-azure-e2e-v2-self-managed workflow that provisions three self-managed Azure guest clusters (public, private, OAuth LB) and runs the v2 Ginkgo test suite against each, producing per-spec JUnit entries for Sippy. Uses domain-based discrimination in the shared install script to select the correct DNS credentials: v2 workflows using the sm.hcp-sm-azure domain get the self-managed DNS service principal, while v1 workflows using the aks-e2e domain keep their original AKS credentials. Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
andrej1991
pushed a commit
to andrej1991/release
that referenced
this pull request
Jul 6, 2026
…t#77674) Adds a new hypershift-azure-e2e-v2-self-managed workflow that provisions three self-managed Azure guest clusters (public, private, OAuth LB) and runs the v2 Ginkgo test suite against each, producing per-spec JUnit entries for Sippy. Uses domain-based discrimination in the shared install script to select the correct DNS credentials: v2 workflows using the sm.hcp-sm-azure domain get the self-managed DNS service principal, while v1 workflows using the aks-e2e domain keep their original AKS credentials. Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
TimurMP
pushed a commit
to TimurMP/release
that referenced
this pull request
Jul 8, 2026
…t#77674) Adds a new hypershift-azure-e2e-v2-self-managed workflow that provisions three self-managed Azure guest clusters (public, private, OAuth LB) and runs the v2 Ginkgo test suite against each, producing per-spec JUnit entries for Sippy. Uses domain-based discrimination in the shared install script to select the correct DNS credentials: v2 workflows using the sm.hcp-sm-azure domain get the self-managed DNS service principal, while v1 workflows using the aks-e2e domain keep their original AKS credentials. Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
SachinNinganure
pushed a commit
to SachinNinganure/release
that referenced
this pull request
Jul 20, 2026
…t#77674) Adds a new hypershift-azure-e2e-v2-self-managed workflow that provisions three self-managed Azure guest clusters (public, private, OAuth LB) and runs the v2 Ginkgo test suite against each, producing per-spec JUnit entries for Sippy. Uses domain-based discrimination in the shared install script to select the correct DNS credentials: v2 workflows using the sm.hcp-sm-azure domain get the self-managed DNS service principal, while v1 workflows using the aks-e2e domain keep their original AKS credentials. Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
malingatembo
pushed a commit
to malingatembo/release
that referenced
this pull request
Aug 5, 2026
…t#77674) Adds a new hypershift-azure-e2e-v2-self-managed workflow that provisions three self-managed Azure guest clusters (public, private, OAuth LB) and runs the v2 Ginkgo test suite against each, producing per-spec JUnit entries for Sippy. Uses domain-based discrimination in the shared install script to select the correct DNS credentials: v2 workflows using the sm.hcp-sm-azure domain get the self-managed DNS service principal, while v1 workflows using the aks-e2e domain keep their original AKS credentials. Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
TimurMP
pushed a commit
to TimurMP/release
that referenced
this pull request
Sep 5, 2026
…t#77674) Adds a new hypershift-azure-e2e-v2-self-managed workflow that provisions three self-managed Azure guest clusters (public, private, OAuth LB) and runs the v2 Ginkgo test suite against each, producing per-spec JUnit entries for Sippy. Uses domain-based discrimination in the shared install script to select the correct DNS credentials: v2 workflows using the sm.hcp-sm-azure domain get the self-managed DNS service principal, while v1 workflows using the aks-e2e domain keep their original AKS credentials. Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
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
4 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
New step registry components
hypershift-azure-e2e-v2-self-managed— workflow: RBAC → nested mgmt cluster → private link setup → HyperShift install → create guests → run tests → destroy guests → destroy mgmt clusterhypershift-azure-create-selfmanaged-guests— creates 3 guest clusters in parallel (public, private w/ PLS, OAuth LB) on the nested management clusterhypershift-azure-run-e2e-v2-selfmanaged— runsbin/test-e2e-self-managed-azure3x with--ginkgo.label-filterper cluster, producing 3 JUnit XML fileshypershift-azure-destroy-selfmanaged-guests— destroys all 3 guest clusters (best_effort)New CI job
e2e-azure-v2-self-managed— optional, triggers on changes totest/e2e/v2/selfmanagedazureortest/e2e/utilcluster_profile: hypershift-azurewith self-managed Azure credentialsDepends on
selfmanaged-azure-e2eMakefile target)Ref: CNTRLPLANE-3222
Generated with Claude Code
Summary by CodeRabbit
New Features
Tests
Chores