[OTA-1545] Extend ClusterVersion for accepted risks

[hongkailiu]

The API extensions is proposed in openshift/enhancements#1807

• Add a new field clusterversion.spec.desiredUpdate.acceptRisks: It
  containsthe names of conditional update risks that are considered
  acceptable.
• Move clusterversion.status.conditionalUpdates.risks two levels up as
  clusterversion.status.conditionalUpdateRisks. It contains all the risks
  for clusterversion.status.conditionalUpdates.
• Add new field 'clusterversion.status.conditionalUpdates.riskNames': It
  contains the names of risk for the conditional update. It deprecates
  clusterversion.status.conditionalUpdates.risks.
• Add a new field 'clusterversion.status.conditionalUpdateRisks.conditions':
  It contains the observations of the conditional update risk's current
  status.

[openshift-ci]

Hello @hongkailiu! Some important instructions when contributing to openshift/api:
API design plays an important part in the user experience of OpenShift and as such API PRs are subject to a high level of scrutiny to ensure they follow our best practices. If you haven't already done so, please review the OpenShift API Conventions and ensure that your proposed changes are compliant. Following these conventions will help expedite the api review process for your PR.

[coderabbitai]

Actionable comments posted: 1

♻️ Duplicate comments (11)

config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator_01_clusterversions-TechPreviewNoUpgrade.crd.yaml (2)

459-618: Remove minItems constraint from status field conditionalUpdateRisks.

At line 614, conditionalUpdateRisks has minItems: 1, but this is a server-generated status field. The system must be able to represent states where no conditional update risks have been identified. Enforcing a minimum of one entry prevents accurate status reporting.

This issue was previously identified in past reviews but remains unresolved.

🔎 Suggested fix

Remove the minItems: 1 constraint:

               maxItems: 500
-              minItems: 1
               type: array

---

743-757: Remove minItems constraint from status field riskNames.

At line 755, riskNames has minItems: 1, but this status field should be able to represent conditional updates with zero applicable risks. The Applies condition in each risk entry determines cluster applicability—an empty riskNames array validly represents an update with no risks applicable to the current cluster.

This issue was previously identified in past reviews but remains unresolved.

🔎 Suggested fix

Remove the minItems: 1 constraint:

               maxItems: 500
-              minItems: 1
               type: array

config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator_01_clusterversions-CustomNoUpgrade.crd.yaml (2)

459-618: Remove minItems constraint from status field conditionalUpdateRisks.

At line 614, conditionalUpdateRisks has minItems: 1 on a server-generated status field. This constraint should be removed to allow the API to accurately represent states with no identified conditional update risks.

This is the same issue present in the TechPreviewNoUpgrade CRD variant and was previously flagged in past reviews.

🔎 Suggested fix

               maxItems: 500
-              minItems: 1
               type: array

---

743-757: Remove minItems constraint from status field riskNames.

At line 755, the riskNames status field has minItems: 1, preventing representation of conditional updates with zero applicable risks. This constraint should be removed.

This is the same issue present in the TechPreviewNoUpgrade CRD variant and was previously flagged in past reviews.

🔎 Suggested fix

               maxItems: 500
-              minItems: 1
               type: array

config/v1/zz_generated.featuregated-crd-manifests/clusterversions.config.openshift.io/ClusterUpdateAcceptRisks.yaml (1)

411-481: Fix docs vs. schema mismatch for conditions length

Both conditionalUpdateRisks[].conditions and conditionalUpdates[].risks[].conditions describe “conditions must not contain more than one entry”, but the schema allows up to 8 entries (maxItems: 8, minItems: 1 with a CEL rule requiring an Applies condition).

Either:

• keep maxItems: 8 and update the descriptions to reflect the actual [1,8] range, or
• change maxItems back to 1 if only a single condition is truly intended.

Given earlier discussions about future headroom, aligning the comments with the current maxItems: 8 constraint is likely the right fix.

Also applies to: 699-770

config/v1/types_cluster_version.go (1)

869-881: Align ConditionalUpdateRisk.Conditions docs with MaxItems=8

The comments state “conditions must not contain more than one entry”, but the markers allow 1–8 entries:

• +kubebuilder:validation:MaxItems=8
• +kubebuilder:validation:MinItems=1
• CEL requires at least one Applies condition.

To avoid confusion, either:

• update the comment to describe the actual [1,8] range (and mention the Applies requirement), or
• lower MaxItems to 1 if only a single condition is really intended (which would also require regenerating CRDs).

Given the prior decision to allow room for more condition types, updating the docs to match MaxItems=8 is the better option.

openapi/generated_openapi/zz_generated.openapi.go (2)

9348-9367: Verify MaxLength constraint was generated for AcceptRisk.name.

The description states "must not exceed 256 characters," but the schema lacks the MaxLength field in SchemaProps. A previous review flagged this same issue and marked it as addressed, yet the constraint is still absent. Verify the source file contains +kubebuilder:validation:MaxLength=256 and re-run OpenAPI generation.

#!/bin/bash
# Verify kubebuilder marker exists in source and check generation timestamp
rg -A 2 'type AcceptRisk struct' config/v1/types_cluster_version.go

# Check if MaxLength appears anywhere in the AcceptRisk schema
rg -A 25 'schema_openshift_api_config_v1_AcceptRisk' openapi/generated_openapi/zz_generated.openapi.go | grep -i maxlength

---

9348-9367: Re-run OpenAPI generation to include all validation constraints.

Multiple schemas are missing validation constraints that are explicitly mentioned in their descriptions but absent from SchemaProps:

1. AcceptRisk.name (lines 9355-9361): Missing MaxLength: 256
2. conditionalUpdateRisks (lines 11688-11699): Missing MaxItems: 500 and MinItems: 1
3. riskNames (lines 11937-11949): Missing MaxItems: 500, MinItems: 1, and items MaxLength: 256
4. conditions (lines 12022-12033): Missing MaxItems: 1
5. acceptRisks (lines 20977-20988): Missing MaxItems: 1000

Previous reviews flagged these issues and marked them as addressed, yet the constraints remain absent in the current code. This suggests the OpenAPI generation step was not re-run after the source fixes, or the generation tooling is not properly translating kubebuilder validation markers into OpenAPI schema constraints.

Since this is a generated file, verify the source (config/v1/types_cluster_version.go) contains the appropriate kubebuilder markers and re-run the OpenAPI generation:

#!/bin/bash
# Verify all kubebuilder validation markers exist in source
echo "=== Checking AcceptRisk.Name ==="
rg -A 3 'type AcceptRisk struct' config/v1/types_cluster_version.go

echo -e "\n=== Checking ConditionalUpdateRisks ==="
rg -B 2 'ConditionalUpdateRisks.*\[\]ConditionalUpdateRisk' config/v1/types_cluster_version.go

echo -e "\n=== Checking riskNames ==="
rg -B 3 'RiskNames.*\[\]string' config/v1/types_cluster_version.go

echo -e "\n=== Checking conditions ==="
rg -B 3 'Conditions.*\[\].*Condition' config/v1/types_cluster_version.go

echo -e "\n=== Checking acceptRisks ==="
rg -B 2 'AcceptRisks.*\[\]AcceptRisk' config/v1/types_cluster_version.go

Also applies to: 11676-11708, 11928-11950, 12010-12034, 20965-20996

config/v1/zz_generated.swagger_doc_generated.go (1)

801-812: Clarify conditionalUpdateRisks doc to match Applies/acceptRisks semantics

The conditionalUpdateRisks description on Line 811 currently implies that all risks for a conditional update must be listed in spec.desiredUpdate.acceptRisks, regardless of whether they actually apply to this cluster. That contradicts the more precise contract described on ConditionalUpdate.riskNames (Line 834), where a conditional update is acceptable if each risk either:

• does not apply (Applies condition is false), or
• applies and its name is present in spec.desiredUpdate.acceptRisks.

Consider rewording the field doc (in config/v1/types_cluster_version.go, then regenerating swagger) to either:

• Explicitly mention the Applies condition, e.g. “Only risks whose Applies condition is true must be present in spec.desiredUpdate.acceptRisks for the update to proceed.”, or
• Keep this field’s text high-level and defer to ConditionalUpdate.riskNames for the exact gating semantics.

This keeps API docs consistent and avoids confusing admins about when a risk must be explicitly accepted.

config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator_01_clusterversions-DevPreviewNoUpgrade.crd.yaml (2)

459-618: Status field should not enforce minItems constraint.

The conditionalUpdateRisks status field at line 614 still has minItems: 1. As flagged in previous reviews, this prevents the system from reporting an empty risks list when no risks are identified for the current cluster state, which is a valid scenario. Status fields should allow empty arrays.

🔎 Recommended fix

Remove the minItems: 1 constraint at line 614:

                maxItems: 500
-               minItems: 1
                type: array

---

743-757: Remove minItems constraint from status riskNames.

The riskNames field at line 755 still enforces minItems: 1, but this is part of the status representation for each conditional update. As previously flagged, a conditional update may legitimately have zero applicable risks for a given cluster, making an empty riskNames array a valid state. This constraint prevents the API from accurately reflecting such situations.

🔎 Recommended fix

Remove the minItems: 1 constraint at line 755:

                maxItems: 500
-               minItems: 1
                type: array

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting

📥 Commits

Reviewing files that changed from the base of the PR and between 7131685 and 607db6f.

📒 Files selected for processing (25)

• config/v1/tests/clusterversions.config.openshift.io/ClusterUpdateAcceptRisks.yaml
• config/v1/types_cluster_version.go
• config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator_01_clusterversions-CustomNoUpgrade.crd.yaml
• config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator_01_clusterversions-Default.crd.yaml
• config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator_01_clusterversions-DevPreviewNoUpgrade.crd.yaml
• config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator_01_clusterversions-OKD.crd.yaml
• config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator_01_clusterversions-TechPreviewNoUpgrade.crd.yaml
• config/v1/zz_generated.deepcopy.go
• config/v1/zz_generated.featuregated-crd-manifests.yaml
• config/v1/zz_generated.featuregated-crd-manifests/clusterversions.config.openshift.io/AAA_ungated.yaml
• config/v1/zz_generated.featuregated-crd-manifests/clusterversions.config.openshift.io/ClusterUpdateAcceptRisks.yaml
• config/v1/zz_generated.featuregated-crd-manifests/clusterversions.config.openshift.io/ImageStreamImportMode.yaml
• config/v1/zz_generated.featuregated-crd-manifests/clusterversions.config.openshift.io/SignatureStores.yaml
• config/v1/zz_generated.swagger_doc_generated.go
• features.md
• features/features.go
• openapi/generated_openapi/zz_generated.openapi.go
• payload-manifests/featuregates/featureGate-Hypershift-Default.yaml
• payload-manifests/featuregates/featureGate-Hypershift-DevPreviewNoUpgrade.yaml
• payload-manifests/featuregates/featureGate-Hypershift-OKD.yaml
• payload-manifests/featuregates/featureGate-Hypershift-TechPreviewNoUpgrade.yaml
• payload-manifests/featuregates/featureGate-SelfManagedHA-Default.yaml
• payload-manifests/featuregates/featureGate-SelfManagedHA-DevPreviewNoUpgrade.yaml
• payload-manifests/featuregates/featureGate-SelfManagedHA-OKD.yaml
• payload-manifests/featuregates/featureGate-SelfManagedHA-TechPreviewNoUpgrade.yaml

🚧 Files skipped from review as they are similar to previous changes (10)

• payload-manifests/featuregates/featureGate-SelfManagedHA-DevPreviewNoUpgrade.yaml
• config/v1/tests/clusterversions.config.openshift.io/ClusterUpdateAcceptRisks.yaml
• features.md
• payload-manifests/featuregates/featureGate-Hypershift-Default.yaml
• config/v1/zz_generated.deepcopy.go
• payload-manifests/featuregates/featureGate-SelfManagedHA-TechPreviewNoUpgrade.yaml
• payload-manifests/featuregates/featureGate-SelfManagedHA-Default.yaml
• config/v1/zz_generated.featuregated-crd-manifests/clusterversions.config.openshift.io/AAA_ungated.yaml
• config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator_01_clusterversions-Default.crd.yaml
• config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator_01_clusterversions-OKD.crd.yaml

🧰 Additional context used

📓 Path-based instructions (1)

**

⚙️ CodeRabbit configuration file

-Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity.

Files:

• features/features.go
• payload-manifests/featuregates/featureGate-Hypershift-TechPreviewNoUpgrade.yaml
• openapi/generated_openapi/zz_generated.openapi.go
• payload-manifests/featuregates/featureGate-SelfManagedHA-OKD.yaml
• config/v1/zz_generated.featuregated-crd-manifests.yaml
• payload-manifests/featuregates/featureGate-Hypershift-DevPreviewNoUpgrade.yaml
• config/v1/types_cluster_version.go
• config/v1/zz_generated.swagger_doc_generated.go
• config/v1/zz_generated.featuregated-crd-manifests/clusterversions.config.openshift.io/ImageStreamImportMode.yaml
• config/v1/zz_generated.featuregated-crd-manifests/clusterversions.config.openshift.io/ClusterUpdateAcceptRisks.yaml
• config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator_01_clusterversions-DevPreviewNoUpgrade.crd.yaml
• config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator_01_clusterversions-TechPreviewNoUpgrade.crd.yaml
• payload-manifests/featuregates/featureGate-Hypershift-OKD.yaml
• config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator_01_clusterversions-CustomNoUpgrade.crd.yaml
• config/v1/zz_generated.featuregated-crd-manifests/clusterversions.config.openshift.io/SignatureStores.yaml

🧬 Code graph analysis (2)

config/v1/types_cluster_version.go (1)

config/v1/zz_generated.swagger_doc_generated.go (3)

• ConditionalUpdate (839-841)
• ConditionalUpdateRisk (852-854)
• AcceptRisk (732-734)

config/v1/zz_generated.swagger_doc_generated.go (1)

config/v1/types_cluster_version.go (1)

• AcceptRisk (766-773)

🔇 Additional comments (22)

payload-manifests/featuregates/featureGate-SelfManagedHA-OKD.yaml (1)

80-82: LGTM! Feature gate addition is correctly positioned.

The "ClusterUpdateAcceptRisks" feature gate entry is properly formatted and alphabetically ordered within the disabled features list, consistent with the PR's objective to introduce risk acceptance functionality for cluster updates.

config/v1/zz_generated.featuregated-crd-manifests/clusterversions.config.openshift.io/ImageStreamImportMode.yaml (1)

589-589: LGTM! Defensive constraints and documentation improvement.

The added maxItems constraints (200 risks per conditional update, 500 total conditional updates) are reasonable defensive limits that prevent unbounded array growth. The typo fix in the acceptedRisks description improves documentation quality.

Also applies to: 599-599, 709-709

features/features.go (1)

669-676: LGTM! Feature gate properly configured.

The FeatureGateClusterUpdateAcceptRisks feature gate is correctly configured with:

• Appropriate Jira component and contact person
• Correct feature sets (DevPreviewNoUpgrade, TechPreviewNoUpgrade)
• Valid enhancement PR reference

The naming follows the established pattern, and the previous typo noted in past reviews has been corrected.

config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator_01_clusterversions-TechPreviewNoUpgrade.crd.yaml (1)

159-186: LGTM! Spec field validation is appropriate.

The acceptRisks field is properly configured as an optional spec field with reasonable constraints:

• minItems: 1 is acceptable here because this is user-provided configuration—if no risks are being accepted, the field can be omitted entirely
• maxItems: 1000 provides a reasonable upper bound
• Map-based list type ensures uniqueness by name
• Field-level validations (maxLength: 256, minLength: 1) are appropriate

payload-manifests/featuregates/featureGate-Hypershift-OKD.yaml (1)

80-82: LGTM! Feature gate correctly disabled for OKD.

The ClusterUpdateAcceptRisks feature gate is appropriately added to the disabled list for the Hypershift-OKD environment, consistent with it being available only in DevPreviewNoUpgrade and TechPreviewNoUpgrade feature sets.

payload-manifests/featuregates/featureGate-Hypershift-DevPreviewNoUpgrade.yaml (1)

133-135: LGTM! Feature gate correctly enabled for DevPreviewNoUpgrade.

The ClusterUpdateAcceptRisks feature gate is appropriately added to the enabled list for the Hypershift-DevPreviewNoUpgrade environment, consistent with the feature gate configuration that enables it for DevPreviewNoUpgrade and TechPreviewNoUpgrade feature sets.

payload-manifests/featuregates/featureGate-Hypershift-TechPreviewNoUpgrade.yaml (1)

145-147: ClusterUpdateAcceptRisks gate wiring looks correct

New feature gate is enabled in the TechPreviewNoUpgrade Hypershift manifest in the same pattern/position as adjacent gates. No issues from a schema or rollout perspective.

config/v1/zz_generated.featuregated-crd-manifests.yaml (1)

143-145: Feature-gated CRD registration is consistent

Adding ClusterUpdateAcceptRisks to the ClusterVersion FeatureGates block matches the new gate and associated CRDs; structure and ordering are fine.

config/v1/zz_generated.featuregated-crd-manifests/clusterversions.config.openshift.io/SignatureStores.yaml (1)

618-620: Array caps and doc tweak align with Go API

maxItems values for status.conditionalUpdates.risks (200) and status.conditionalUpdates (500) match the Go +kubebuilder:validation:MaxItems markers and help keep CRD cost reasonable; the acceptedRisks description fix is also correct. No further changes needed.

Also applies to: 628-628, 727-731

config/v1/types_cluster_version.go (2)

195-205: Status-level conditional update caps and risk aggregation look good

Capping ConditionalUpdates at 500 and adding ConditionalUpdateRisks (map keyed by name, max 500, min 1) matches the generated CRDs and the intended aggregation model. This should keep CRD/CEL cost under control while preserving enough headroom for real-world graphs.

Also applies to: 207-218

---

828-840: RiskNames and Risks constraints are consistent and appropriate

The new RiskNames field (min 1, max 500, per-item max length 256, set semantics) and Risks cap (MaxItems=200 with MinItems=1) align with the CRD schema and the expected usage patterns. This balances etcd/CRD cost concerns with practical headroom; no further changes needed here.

Also applies to: 847-848

openapi/generated_openapi/zz_generated.openapi.go (3)

166-172: LGTM!

The registration of the AcceptRisk schema in the OpenAPI definitions map is correct.

---

12080-12086: LGTM!

The dependency on k8s.io/apimachinery/pkg/apis/meta/v1.Condition is correctly added to match the conditions field reference.

---

21048-21054: LGTM!

The description update clarifies what acceptedRisks records, providing better documentation for API users.

config/v1/zz_generated.swagger_doc_generated.go (5)

727-734: AcceptRisk Swagger docs match struct validation

Description and length constraints for name align with AcceptRisk in types_cluster_version.go (non-empty, ≤256 chars). No issues.

---

831-836: riskNames documentation accurately reflects conditional-update gating

The riskNames description clearly ties each name to conditionalUpdateRisks, explains the Applies condition, and states the “does not apply or is accepted” rule, along with uniqueness and cardinality limits. Looks correct and complete.

---

843-850: ConditionalUpdateRisk.conditions constraints are coherent

Doc correctly introduces the Applies condition, enforces unique types, and caps the list at one entry, matching the “single-condition” intent from the PR. No further changes needed.

---

888-895: acceptRisks field description aligns with intended behavior

The doc explains the role of acceptRisks, its relationship to conditional-update risks across releases, and uniqueness/cardinality limits. Semantics are consistent with the new AcceptRisk type and the conditional-update flow.

---

901-910: acceptedRisks history documentation is precise and user-facing

The updated description for UpdateHistory.acceptedRisks clearly conveys what is recorded (force overrides, non-recommended targets, etc.) and fixes the previous typo. No issues.

config/v1/zz_generated.crd-manifests/0000_00_cluster-version-operator_01_clusterversions-DevPreviewNoUpgrade.crd.yaml (3)

159-186: Well-designed acceptRisks field structure.

The acceptRisks field properly uses minItems: 1 with "optional" semantics, meaning administrators don't have to set the field, but if they do, they must provide at least one entry. This prevents accidentally submitting an empty risk acceptance list. The validation constraints (maxItems: 1000, name length 1-256, unique names via map-type) are appropriate.

---

770-841: Strong validation for risk conditions.

The conditions array properly enforces constraints through both schema validation (minItems: 1, maxItems: 8) and CEL validation requiring exactly one condition of type 'Applies'. This ensures risks always have applicability status while allowing room for additional condition types in the future.

---

1033-1033: Good catch on the typo fix.

Correcting "menition" to "mention" improves the documentation quality.

[hongkailiu]

The "unknown version reference "machine-os"" from the okd-scos-images job is caused by this.

We will have to wait for its fix, right?

The budget error on crdify. @JoelSpeed I guess you will override it if I understand the covnersation correctly.

Let me know if you need me to do anything else for this pull.

[JoelSpeed]

/override ci/prow/verify-crdify

We are adding high limits to existing lists, and are confident this shouldn't impact existing clusters

/override ci/prow/okd-scos-images

Known issue with this job

[openshift-ci]

@JoelSpeed: Overrode contexts on behalf of JoelSpeed: ci/prow/okd-scos-images, ci/prow/verify-crdify

Details

In response to this:

/override ci/prow/verify-crdify

We are adding high limits to existing lists, and are confident this shouldn't impact existing clusters

/override ci/prow/okd-scos-images

Known issue with this job

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.

[hongkailiu]

@JoelSpeed

@wking is cool with the limits (and the pruning on the CVO implementation).

This one is good to go!

[JoelSpeed]

/lgtm

[openshift-ci-robot]

Scheduling tests matching the pipeline_run_if_changed or not excluded by pipeline_skip_if_only_changed parameters:
/test e2e-aws-ovn
/test e2e-aws-ovn-hypershift
/test e2e-aws-ovn-hypershift-conformance
/test e2e-aws-ovn-techpreview
/test e2e-aws-serial-1of2
/test e2e-aws-serial-2of2
/test e2e-aws-serial-techpreview-1of2
/test e2e-aws-serial-techpreview-2of2
/test e2e-azure
/test e2e-gcp
/test e2e-upgrade
/test e2e-upgrade-out-of-change

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: everettraven, JoelSpeed, petr-muller

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 [JoelSpeed,everettraven]

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

[hongkailiu]

/retest-required

[hongkailiu]

The failure seems not relevant to this pull and there are green runs from other pulls.

/retest-required

[hongkailiu]

/test e2e-gcp

[JoelSpeed]

/override ci/prow/e2e-aws-serial-techpreview
/override ci/prow/e2e-aws-serial

An issue with the pipeline controller, these shouldn't be on this PR

[openshift-ci]

@JoelSpeed: Overrode contexts on behalf of JoelSpeed: ci/prow/e2e-aws-serial, ci/prow/e2e-aws-serial-techpreview

Details

In response to this:

/override ci/prow/e2e-aws-serial-techpreview
/override ci/prow/e2e-aws-serial

An issue with the pipeline controller, these shouldn't be on this PR

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.

[hongkailiu]

/verified by "CI"

[openshift-ci-robot]

@hongkailiu: This PR has been marked as verified by "CI".

Details

In response to this:

/verified by "CI"

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]

/retest-required

Remaining retests: 0 against base HEAD 6d35063 and 2 for PR HEAD 607db6f in total

[openshift-ci-robot]

/retest-required

Remaining retests: 0 against base HEAD e20773b and 1 for PR HEAD 607db6f in total

[openshift-ci]

@hongkailiu: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/okd-scos-e2e-aws-ovn	0d84d57	link	false	/test okd-scos-e2e-aws-ovn

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.

[wking]

@JoelSpeed would it be up to you to /override ci/prow/verify-crdify? It's currently failing:

F0108 21:30:11.020774   11064 root.go:64] Error running codegen: 
error running generator crdify on group config.openshift.io: 
              
	could not run crdify generator for group/version config.openshift.io/v1: 
		(v1) ^.status.conditionalUpdates - maxItems: 
			maximum constraint added when there was none previously : 500
		(v1) ^.status.conditionalUpdates[*].risks - maxItems: 
              
			maximum constraint added when there was none previously : 200
...

And after a lot of discussion on this pull, I think all of those are intentional tightenings, and we have a plan (OTA-1805) to derisk if we're flubbing our assessments (although with the current numbers, I'd be extremely surprised if they tripped any existing cluster).

Ah, and looks like you'd done that before, but because Prow wants fresh success after some unrelated pull merged, you're on the hook to keep doing it until the run you override happens to stay fresh long enough for us to merge before some other API change merges and makes your override stale 😅

[JoelSpeed]

/override ci/prow/verify-crdify

Intentional tightening that we have discussed

[openshift-ci]

@JoelSpeed: Overrode contexts on behalf of JoelSpeed: ci/prow/verify-crdify

Details

In response to this:

/override ci/prow/verify-crdify

Intentional tightening that we have discussed

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.