Skip to content

OCPBUGS-100301: fix(hostedcluster): handle Unknown status in ClusterVersionFailing inversion - #9186

Merged
openshift-merge-bot[bot] merged 1 commit into
openshift:mainfrom
reedcort:OCPBUGS-100301
Aug 4, 2026
Merged

OCPBUGS-100301: fix(hostedcluster): handle Unknown status in ClusterVersionFailing inversion#9186
openshift-merge-bot[bot] merged 1 commit into
openshift:mainfrom
reedcort:OCPBUGS-100301

Conversation

@reedcort

@reedcort reedcort commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

What this PR does / why we need it:

The ClusterVersionFailing → ClusterVersionSucceeding condition inversion switch (hostedcluster_controller.go:755-762) only handled True and False. When ClusterVersionFailing had Status: Unknown (common during control plane disruptions like cluster-size-override), the switch fell through and set ClusterVersionSucceeding.Status to "" (zero value). The API server permanently rejects this on Status().Update, blocking the entire reconcile loop before Phase 7 (CoreHCPChain). This prevented HC-to-HCP annotation sync, causing request-serving pods to schedule with stale node affinity and remain Pending indefinitely.

This fix adds a default case that maps Unknown (and any other unexpected status) to ConditionUnknown. Applied to both reconcile and reconcileLegacy paths.

Which issue(s) this PR fixes:

Fixes OCPBUGS-100301

Special notes for your reviewer:

Two production incidents: 105 min and 44 hours downtime (ROSAENG-62684).

Root cause confirmed by operator logs showing status.conditions[4].status: Unsupported value: "" and HCP showing ClusterVersionFailing: Unknown.

Bug reproduced on staging cluster by stripping ClusterVersion conditions from the guest cluster:

oc patch clusterversion version --type=json -p '[{"op":"remove","path":"/status/conditions"}]' --subresource=status

This caused the HCCO to set ClusterVersionFailing: Unknown on the HCP, which immediately triggered the same error loop observed in production:

{"level":"error","msg":"Reconciler error","controller":"hostedcluster","error":"[failed to update status: HostedCluster is invalid: [status.conditions[4].status: Unsupported value: \"\": supported values: \"True\", \"False\", \"Unknown\"..."}

Checklist:

  • Subject and description added to both, commit and PR.
  • Relevant issues have been referenced.
  • This change includes docs.
  • This change includes unit tests.

@openshift-merge-bot

Copy link
Copy Markdown
Contributor

Pipeline controller notification
This repo is configured to use the pipeline controller. Second-stage tests will be triggered either automatically or after lgtm label is added, depending on the repository configuration. The pipeline controller will automatically detect which contexts are required and will utilize /test Prow commands to trigger the second stage.

For optional jobs, comment /test ? to see a list of all defined jobs. To trigger manually all jobs from second stage use /pipeline required command.

This repository is configured in: LGTM mode

@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Jul 30, 2026
@openshift-ci-robot

openshift-ci-robot commented Jul 30, 2026

Copy link
Copy Markdown

@reedcort: This pull request references Jira Issue OCPBUGS-100301, which is invalid:

  • expected the bug to target the "5.0.0" version, but no target version was set

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

Details

In response to this:

What this PR does / why we need it:

The ClusterVersionFailing → ClusterVersionSucceeding condition inversion switch (hostedcluster_controller.go:755-762) only handled True and False. When ClusterVersionFailing had Status: Unknown (common during control plane disruptions like cluster-size-override), the switch fell through and set ClusterVersionSucceeding.Status to "" (zero value). The API server permanently rejects this on Status().Update, blocking the entire reconcile loop before Phase 7 (CoreHCPChain). This prevented HC-to-HCP annotation sync, causing request-serving pods to schedule with stale node affinity and remain Pending indefinitely.

This fix adds a default case that maps Unknown (and any other unexpected status) to ConditionUnknown. Applied to both reconcile and reconcileLegacy paths.

Which issue(s) this PR fixes:

Fixes OCPBUGS-100301

Special notes for your reviewer:

Latent bug since Nov 2022 (commit 5627f4a), newly exposed by the cluster-size-override workflow. Two production incidents: 105 min and 44 hours downtime (ROSAENG-62684). Root cause confirmed by operator logs showing status.conditions[4].status: Unsupported value: "" and HCP showing ClusterVersionFailing: Unknown.

Checklist:

  • Subject and description added to both, commit and PR.
  • Relevant issues have been referenced.
  • This change includes docs.
  • This change includes unit tests.

Instructions 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 openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot openshift-ci-robot added the jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. label Jul 30, 2026
@openshift-ci openshift-ci Bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jul 30, 2026
@openshift-ci

openshift-ci Bot commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@coderabbitai

coderabbitai Bot commented Jul 30, 2026

Copy link
Copy Markdown
Contributor
📝 Walkthrough

Walkthrough

HostedCluster condition inversion now explicitly maps unrecognized CVO statuses to ConditionUnknown in both controller paths. A new table-driven unit test covers True, False, and Unknown source statuses and verifies the resulting ClusterVersionSucceeding condition.

Suggested reviewers: muraee, mgencur, bryan-cox

🚥 Pre-merge checks | ✅ 11
✅ Passed checks (11 passed)
Check name Status Explanation
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.
Stable And Deterministic Test Names ✅ Passed New test titles are static strings; no dynamic names, timestamps, UUIDs, or generated identifiers were introduced.
Test Structure And Quality ✅ Passed PASS: the new table-driven unit test is focused on one behavior, has no cluster resources or waits, and matches existing repo unit-test style.
Topology-Aware Scheduling Compatibility ✅ Passed Only condition-status inversion fallback and a unit test changed; no pod specs, replicas, selectors, affinities, or topology-aware scheduling logic were added.
Ipv6 And Disconnected Network Test Compatibility ✅ Passed The added test is a Go unit test (testing.T/t.Run/NewWithT), not a Ginkgo e2e test, and it contains no IPv4-only or external-network assumptions.
No-Weak-Crypto ✅ Passed Changed hunks only adjust condition-status inversion and tests; no weak-crypto APIs or secret/token comparisons appear in the diff.
Container-Privileges ✅ Passed The PR only changes CVO status inversion logic and a unit test; no manifest or securityContext changes add privileged, hostPID/Network/IPC, SYS_ADMIN, or allowPrivilegeEscalation.
No-Sensitive-Data-In-Logs ✅ Passed No new logging was added in the touched diff; the change only alters condition status mapping and adds a unit test with non-sensitive literals.
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly identifies the hostedcluster inversion fix for Unknown ClusterVersionFailing status, which matches the main changes.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

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

@openshift-ci openshift-ci Bot added area/hypershift-operator Indicates the PR includes changes for the hypershift operator and API - outside an OCP release and removed do-not-merge/needs-area labels Jul 30, 2026
@reedcort

Copy link
Copy Markdown
Contributor Author

/jira refresh

@openshift-ci-robot openshift-ci-robot added jira/valid-bug Indicates that a referenced Jira bug is valid for the branch this PR is targeting. and removed jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. labels Jul 30, 2026
@openshift-ci-robot

Copy link
Copy Markdown

@reedcort: This pull request references Jira Issue OCPBUGS-100301, which is valid. The bug has been moved to the POST state.

3 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target version (5.0.0) matches configured target version for branch (5.0.0)
  • bug is in the state ASSIGNED, which is one of the valid states (NEW, ASSIGNED, POST)
Details

In response to this:

/jira refresh

Instructions 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 openshift-eng/jira-lifecycle-plugin repository.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

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
`@hypershift-operator/controllers/hostedcluster/hostedcluster_controller_test.go`:
- Around line 4046-4077: Replace the duplicated condition-map and
status-inversion logic in the test with coverage of the production
reconciliation behavior: either extract a shared helper used by both reconcile
and reconcileLegacy and test that helper, or invoke each reconciler with an
appropriate fake client. Ensure the tests exercise missing-condition fallbacks
and inversion outcomes, and add or update unit tests for the production code
changes.
- Around line 4016-4020: Add a table-driven test case alongside the existing
ClusterVersionFailing status cases using metav1.ConditionStatus("Unexpected") as
hcpStatus and metav1.ConditionUnknown as expectedStatus, covering fallback
statuses beyond the named ConditionUnknown constant.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: ee96441a-2b5f-40c1-994d-05a9bcaa2130

📥 Commits

Reviewing files that changed from the base of the PR and between 1c9f189 and be6e52b.

📒 Files selected for processing (3)
  • hypershift-operator/controllers/hostedcluster/hostedcluster_controller.go
  • hypershift-operator/controllers/hostedcluster/hostedcluster_controller_test.go
  • hypershift-operator/controllers/hostedcluster/reconcile_legacy.go

Comment on lines +4016 to +4020
{
name: "When ClusterVersionFailing is Unknown it should produce ClusterVersionSucceeding Unknown",
hcpStatus: metav1.ConditionUnknown,
expectedStatus: metav1.ConditionUnknown,
},

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Cover unexpected statuses beyond ConditionUnknown.

The new fallback handles every status other than True and False, but the table only tests the named Unknown constant. Add a case such as metav1.ConditionStatus("Unexpected") and expect metav1.ConditionUnknown.

As per coding guidelines, unit test any code changes and additions.

🤖 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
`@hypershift-operator/controllers/hostedcluster/hostedcluster_controller_test.go`
around lines 4016 - 4020, Add a table-driven test case alongside the existing
ClusterVersionFailing status cases using metav1.ConditionStatus("Unexpected") as
hcpStatus and metav1.ConditionUnknown as expectedStatus, covering fallback
statuses beyond the named ConditionUnknown constant.

Source: Coding guidelines

Comment on lines +4046 to +4077
hcpCVOConditions := map[hyperv1.ConditionType]*metav1.Condition{
hyperv1.ClusterVersionSucceeding: meta.FindStatusCondition(hcp.Status.Conditions, string(hyperv1.ClusterVersionFailing)),
}

for conditionType := range hcpCVOConditions {
hcCVOCondition := &metav1.Condition{
Type: string(conditionType),
Status: metav1.ConditionUnknown,
Reason: hyperv1.StatusUnknownReason,
ObservedGeneration: hcluster.Generation,
}

if hcpCVOConditions[conditionType] != nil {
hcCVOCondition = hcpCVOConditions[conditionType]
hcCVOCondition.ObservedGeneration = hcluster.Generation

if conditionType == hyperv1.ClusterVersionSucceeding {
hcCVOCondition.Type = string(hyperv1.ClusterVersionSucceeding)
var status metav1.ConditionStatus
switch hcpCVOConditions[conditionType].Status {
case metav1.ConditionTrue:
status = metav1.ConditionFalse
case metav1.ConditionFalse:
status = metav1.ConditionTrue
default:
status = metav1.ConditionUnknown
}
hcCVOCondition.Status = status
}
}

meta.SetStatusCondition(&hcluster.Status.Conditions, *hcCVOCondition)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift

Exercise the production reconciliation code instead of copying its implementation.

This test reconstructs the same map and switch as production, so it can pass even if reconcile or reconcileLegacy omits or mishandles the fallback. Extract a shared inversion helper used by both paths and test that helper, or invoke each reconciler with an appropriate fake client.

As per coding guidelines, unit test any code changes and additions.

🤖 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
`@hypershift-operator/controllers/hostedcluster/hostedcluster_controller_test.go`
around lines 4046 - 4077, Replace the duplicated condition-map and
status-inversion logic in the test with coverage of the production
reconciliation behavior: either extract a shared helper used by both reconcile
and reconcileLegacy and test that helper, or invoke each reconciler with an
appropriate fake client. Ensure the tests exercise missing-condition fallbacks
and inversion outcomes, and add or update unit tests for the production code
changes.

Source: Coding guidelines

@codecov

codecov Bot commented Jul 30, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 88.88889% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 44.95%. Comparing base (60ada1e) to head (d9edcc4).
⚠️ Report is 32 commits behind head on main.

Files with missing lines Patch % Lines
...trollers/hostedcluster/hostedcluster_controller.go 88.88% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #9186      +/-   ##
==========================================
+ Coverage   44.81%   44.95%   +0.13%     
==========================================
  Files         775      778       +3     
  Lines       97219    97430     +211     
==========================================
+ Hits        43572    43798     +226     
+ Misses      50644    50611      -33     
- Partials     3003     3021      +18     
Files with missing lines Coverage Δ
...trollers/hostedcluster/hostedcluster_controller.go 54.82% <88.88%> (+0.14%) ⬆️

... and 26 files with indirect coverage changes

Flag Coverage Δ
cmd-support 38.62% <ø> (+0.20%) ⬆️
cpo-hostedcontrolplane 47.28% <ø> (-0.04%) ⬇️
cpo-other 45.67% <ø> (ø)
hypershift-operator 54.95% <88.88%> (+0.31%) ⬆️
other 34.32% <ø> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@reedcort
reedcort marked this pull request as ready for review July 31, 2026 12:51
@openshift-ci openshift-ci Bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jul 31, 2026
@openshift-ci
openshift-ci Bot requested review from bryan-cox and sdminonne July 31, 2026 12:51
@joshbranham

Copy link
Copy Markdown
Contributor

/lgtm

@openshift-ci openshift-ci Bot added the lgtm Indicates that a PR is ready to be merged. label Jul 31, 2026
@openshift-merge-bot

Copy link
Copy Markdown
Contributor

Scheduling tests matching the pipeline_run_if_changed or not excluded by pipeline_skip_if_only_changed parameters:
/test e2e-aks-4-22
/test e2e-aws-4-22
/test e2e-aks
/test e2e-aws
/test e2e-aws-upgrade-hypershift-operator
/test e2e-kubevirt-aws-ovn-reduced
/test e2e-v2-aws
/test e2e-v2-azure-self-managed
/test e2e-v2-gke
/test unit
/test verify

@cwbotbot

cwbotbot commented Jul 31, 2026

Copy link
Copy Markdown

Test Results

e2e-aws

e2e-aks

@openshift-ci-robot

Copy link
Copy Markdown

@reedcort: This pull request references Jira Issue OCPBUGS-100301, which is valid.

3 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target version (5.0.0) matches configured target version for branch (5.0.0)
  • bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)
Details

In response to this:

What this PR does / why we need it:

The ClusterVersionFailing → ClusterVersionSucceeding condition inversion switch (hostedcluster_controller.go:755-762) only handled True and False. When ClusterVersionFailing had Status: Unknown (common during control plane disruptions like cluster-size-override), the switch fell through and set ClusterVersionSucceeding.Status to "" (zero value). The API server permanently rejects this on Status().Update, blocking the entire reconcile loop before Phase 7 (CoreHCPChain). This prevented HC-to-HCP annotation sync, causing request-serving pods to schedule with stale node affinity and remain Pending indefinitely.

This fix adds a default case that maps Unknown (and any other unexpected status) to ConditionUnknown. Applied to both reconcile and reconcileLegacy paths.

Which issue(s) this PR fixes:

Fixes OCPBUGS-100301

Special notes for your reviewer:

Two production incidents: 105 min and 44 hours downtime (ROSAENG-62684).

Root cause confirmed by operator logs showing status.conditions[4].status: Unsupported value: "" and HCP showing ClusterVersionFailing: Unknown.

Bug reproduced on staging cluster by stripping ClusterVersion conditions from the guest cluster:

oc patch clusterversion version --type=json -p '[{"op":"remove","path":"/status/conditions"}]' --subresource=status

This caused the HCCO to set ClusterVersionFailing: Unknown on the HCP, which immediately triggered the same error loop observed in production:

{"level":"error","msg":"Reconciler error","controller":"hostedcluster","error":"[failed to update status: HostedCluster is invalid: [status.conditions[4].status: Unsupported value: \"\": supported values: \"True\", \"False\", \"Unknown\"..."}

Checklist:

  • Subject and description added to both, commit and PR.
  • Relevant issues have been referenced.
  • This change includes docs.
  • This change includes unit tests.

Instructions 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 openshift-eng/jira-lifecycle-plugin repository.

@bryan-cox bryan-cox left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

The fix is correct and addresses two production incidents.

Comment on lines +761 to +762
default:
status = metav1.ConditionUnknown

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Suggestion: The identical inversion switch exists in reconcile_legacy.go:441. Consider extracting a shared helper to eliminate the duplication:

func invertConditionStatus(s metav1.ConditionStatus) metav1.ConditionStatus {
	switch s {
	case metav1.ConditionTrue:
		return metav1.ConditionFalse
	case metav1.ConditionFalse:
		return metav1.ConditionTrue
	default:
		return metav1.ConditionUnknown
	}
}

The project already does this with computeClusterVersionStatus() which is shared between both paths. This would also let the test exercise the actual production function instead of re-implementing the logic inline.

Comment on lines +4024 to +4025
t.Run(tc.name, func(t *testing.T) {
g := NewWithT(t)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Suggestion: The subtests should call t.Parallel() — other subtests in this file do (e.g., TestComputeAWSDefaultSGDeletedCondition). Since these cases are independent:

t.Run(tc.name, func(t *testing.T) {
	t.Parallel()
	g := NewWithT(t)

Comment on lines +4066 to +4075
case metav1.ConditionTrue:
status = metav1.ConditionFalse
case metav1.ConditionFalse:
status = metav1.ConditionTrue
default:
status = metav1.ConditionUnknown
}
hcCVOCondition.Status = status
}
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Suggestion: This test re-implements the inversion switch inline rather than calling reconcile() or reconcileLegacy(). If the production code is changed but this test isn't updated (or vice versa), the test will still pass while the production path is broken.

If extracting invertConditionStatus() is too much for a bug-fix PR, at minimum the test name should clarify it's testing the logic in isolation, not the code path.

name: "When ClusterVersionFailing is Unknown it should produce ClusterVersionSucceeding Unknown",
hcpStatus: metav1.ConditionUnknown,
expectedStatus: metav1.ConditionUnknown,
},

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Suggestion: Consider adding a fourth test case for hcpStatus: "" (empty string). That's the exact zero-value that triggered the original production bug, and it would also hit the default branch:

{
	name:           "When ClusterVersionFailing has empty status it should produce ClusterVersionSucceeding Unknown",
	hcpStatus:      metav1.ConditionStatus(""),
	expectedStatus: metav1.ConditionUnknown,
},

}
}

func TestCVOConditionInversion(t *testing.T) {

@bryan-cox bryan-cox Aug 3, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Per TESTING.md, test function names should map 1:1 to the function under test. Since this doesn't call a production function directly, the name TestCVOConditionInversion is fine as-is. But if you extract the helper, rename to TestInvertConditionStatus to match.

@openshift-ci openshift-ci Bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 3, 2026
@bryan-cox

Copy link
Copy Markdown
Member

/approve cancel

@openshift-ci openshift-ci Bot removed the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 3, 2026
…version

The ClusterVersionFailing → ClusterVersionSucceeding condition inversion
switch only handled True and False. When ClusterVersionFailing had Status:
Unknown (common during control plane disruptions), the switch fell through
and set ClusterVersionSucceeding.Status to "" (zero value), which the API
server permanently rejects on Status().Update. This blocked the entire
reconcile loop, preventing HC-to-HCP annotation sync and causing a
scheduling deadlock where request-serving pods remained Pending
indefinitely.

Extract invertConditionStatus() helper shared by both reconcile and
reconcileLegacy paths, with a default case mapping Unknown and any
unexpected status to ConditionUnknown.

Fixes: OCPBUGS-100301

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@openshift-ci openshift-ci Bot removed the lgtm Indicates that a PR is ready to be merged. label Aug 3, 2026

@joshbranham joshbranham left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

/lgtm

@openshift-ci openshift-ci Bot added the lgtm Indicates that a PR is ready to be merged. label Aug 3, 2026
@openshift-merge-bot

Copy link
Copy Markdown
Contributor

Scheduling tests matching the pipeline_run_if_changed or not excluded by pipeline_skip_if_only_changed parameters:
/test e2e-aks-4-22
/test e2e-aws-4-22
/test e2e-aks
/test e2e-aws
/test e2e-aws-upgrade-hypershift-operator
/test e2e-kubevirt-aws-ovn-reduced
/test e2e-v2-aws
/test e2e-v2-azure-self-managed
/test e2e-v2-gke

@csrwng csrwng added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 3, 2026
@openshift-ci

openshift-ci Bot commented Aug 3, 2026

Copy link
Copy Markdown
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bryan-cox, reedcort

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:

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

@reedcort

reedcort commented Aug 3, 2026

Copy link
Copy Markdown
Contributor Author

/verified by @reedcort via unit tests

@openshift-ci-robot openshift-ci-robot added the verified Signifies that the PR passed pre-merge verification criteria label Aug 3, 2026
@openshift-ci-robot

Copy link
Copy Markdown

@reedcort: This PR has been marked as verified by @reedcort via unit tests.

Details

In response to this:

/verified by @reedcort via unit tests

Instructions 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 openshift-eng/jira-lifecycle-plugin repository.

@openshift-merge-bot

Copy link
Copy Markdown
Contributor

/retest-required

Remaining retests: 0 against base HEAD 923aba2 and 2 for PR HEAD d9edcc4 in total

@joshbranham

Copy link
Copy Markdown
Contributor

/retest-required

@joshbranham

Copy link
Copy Markdown
Contributor

/test e2e-kubevirt-aws-ovn-reduced

2 similar comments
@joshbranham

Copy link
Copy Markdown
Contributor

/test e2e-kubevirt-aws-ovn-reduced

@reedcort

reedcort commented Aug 4, 2026

Copy link
Copy Markdown
Contributor Author

/test e2e-kubevirt-aws-ovn-reduced

@openshift-ci

openshift-ci Bot commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

@reedcort: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions 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.

@openshift-merge-bot
openshift-merge-bot Bot merged commit 2204ef8 into openshift:main Aug 4, 2026
43 checks passed
@openshift-ci-robot

Copy link
Copy Markdown

@reedcort: Jira Issue Verification Checks: Jira Issue OCPBUGS-100301
✔️ This pull request was pre-merge verified.
✔️ All associated pull requests have merged.
✔️ All associated, merged pull requests were pre-merge verified.

Jira Issue OCPBUGS-100301 has been moved to the MODIFIED state and will move to the VERIFIED state when the change is available in an accepted nightly payload. 🕓

Details

In response to this:

What this PR does / why we need it:

The ClusterVersionFailing → ClusterVersionSucceeding condition inversion switch (hostedcluster_controller.go:755-762) only handled True and False. When ClusterVersionFailing had Status: Unknown (common during control plane disruptions like cluster-size-override), the switch fell through and set ClusterVersionSucceeding.Status to "" (zero value). The API server permanently rejects this on Status().Update, blocking the entire reconcile loop before Phase 7 (CoreHCPChain). This prevented HC-to-HCP annotation sync, causing request-serving pods to schedule with stale node affinity and remain Pending indefinitely.

This fix adds a default case that maps Unknown (and any other unexpected status) to ConditionUnknown. Applied to both reconcile and reconcileLegacy paths.

Which issue(s) this PR fixes:

Fixes OCPBUGS-100301

Special notes for your reviewer:

Two production incidents: 105 min and 44 hours downtime (ROSAENG-62684).

Root cause confirmed by operator logs showing status.conditions[4].status: Unsupported value: "" and HCP showing ClusterVersionFailing: Unknown.

Bug reproduced on staging cluster by stripping ClusterVersion conditions from the guest cluster:

oc patch clusterversion version --type=json -p '[{"op":"remove","path":"/status/conditions"}]' --subresource=status

This caused the HCCO to set ClusterVersionFailing: Unknown on the HCP, which immediately triggered the same error loop observed in production:

{"level":"error","msg":"Reconciler error","controller":"hostedcluster","error":"[failed to update status: HostedCluster is invalid: [status.conditions[4].status: Unsupported value: \"\": supported values: \"True\", \"False\", \"Unknown\"..."}

Checklist:

  • Subject and description added to both, commit and PR.
  • Relevant issues have been referenced.
  • This change includes docs.
  • This change includes unit tests.

Instructions 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 openshift-eng/jira-lifecycle-plugin repository.

@openshift-merge-robot

Copy link
Copy Markdown
Contributor

Fix included in release 5.0.0-0.nightly-2026-08-04-172547

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. area/hypershift-operator Indicates the PR includes changes for the hypershift operator and API - outside an OCP release jira/valid-bug Indicates that a referenced Jira bug is valid for the branch this PR is targeting. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. lgtm Indicates that a PR is ready to be merged. verified Signifies that the PR passed pre-merge verification criteria

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants