OCPBUGS-68343: Introduce KMSEncryption feature gate

[ardaguclu]

User description

As we discussed in openshift/enhancements#1900. We need to allow nil KMSConfig, when encryption type is set to KMS.

This PR introduces new KMSEncryption feature gate to exclude KMSConfig which is only enabled when KMSEncryptionProvider feature gate.

---

PR Type

Enhancement

---

Description

• Relax KMS validation rule to allow nil KMSConfig when encryption type is KMS

• Update validation message to only forbid kms config for non-KMS encryption types

• Add test case verifying KMS type with nil kms config is accepted

• Update all CRD manifests and generated files with new validation rule

---

Diagram Walkthrough

flowchart LR
  A["Old Validation Rule"] -->|"Requires kms config<br/>when type=KMS"| B["Strict Validation"]
  C["New Validation Rule"] -->|"Allows nil kms config<br/>when type=KMS"| D["Relaxed Validation"]
  B -->|"PR Changes"| D
  E["Test Case Added"] -->|"Validates KMS type<br/>with nil config"| D

Loading

File Walkthrough

	Relevant files
Enhancement	1 files types_apiserver.go Update KMS validation rule to allow nil config                      +1/-1
Tests	1 files KMSEncryptionProvider.yaml Add test for KMS type with nil kms config                                +10/-4
Configuration changes	7 files 0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml Update KMS validation in CustomNoUpgrade CRD manifest        +2/-4      0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml Update KMS validation in DevPreviewNoUpgrade CRD manifest +2/-4      0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml Update KMS validation in TechPreviewNoUpgrade CRD manifest +2/-4      KMSEncryptionProvider.yaml Update KMS validation in featuregated CRD manifest              +2/-4      0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml Update KMS validation in payload CustomNoUpgrade CRD          +2/-4      0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml Update KMS validation in payload DevPreviewNoUpgrade CRD  +2/-4      0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml Update KMS validation in payload TechPreviewNoUpgrade CRD +2/-4
Documentation	1 files openapi.json Update OpenAPI schema with validation and documentation changes +17/-12

---

[openshift-ci-robot]

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]

@ardaguclu: This pull request references CNTRLPLANE-2241 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

As we discussed in openshift/enhancements#1900. We need to allow nil KMSConfig, when encryption type is set to KMS.

This PR loosen the validation to achieve this.

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]

Hello @ardaguclu! 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.

[openshift-ci-robot]

@ardaguclu: This pull request references CNTRLPLANE-2241 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

User description

As we discussed in openshift/enhancements#1900. We need to allow nil KMSConfig, when encryption type is set to KMS.

This PR loosen the validation to achieve this.

---

PR Type

Enhancement

---

Description

• Relax KMS validation rule to allow nil KMSConfig when encryption type is KMS

• Update validation message to only forbid kms config for non-KMS encryption types

• Add test case verifying KMS type with nil kms config is accepted

• Update all CRD manifests and generated files with new validation rule

---

Diagram Walkthrough

flowchart LR
 A["Old Validation Rule"] -->|"Requires kms config<br/>when type=KMS"| B["Strict Validation"]
 C["New Validation Rule"] -->|"Allows nil kms config<br/>when type=KMS"| D["Relaxed Validation"]
 B -->|"PR Changes"| D
 E["Test Case Added"] -->|"Validates KMS type<br/>with nil config"| D

Loading

File Walkthrough

	Relevant files
Enhancement	1 files types_apiserver.go Update KMS validation rule to allow nil config                      +1/-1
Tests	1 files KMSEncryptionProvider.yaml Add test for KMS type with nil kms config                                +10/-4
Configuration changes	7 files 0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml Update KMS validation in CustomNoUpgrade CRD manifest        +2/-4      0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml Update KMS validation in DevPreviewNoUpgrade CRD manifest +2/-4      0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml Update KMS validation in TechPreviewNoUpgrade CRD manifest +2/-4      KMSEncryptionProvider.yaml Update KMS validation in featuregated CRD manifest              +2/-4      0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml Update KMS validation in payload CustomNoUpgrade CRD          +2/-4      0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml Update KMS validation in payload DevPreviewNoUpgrade CRD  +2/-4      0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml Update KMS validation in payload TechPreviewNoUpgrade CRD +2/-4
Documentation	1 files openapi.json Update OpenAPI schema with validation and documentation changes +17/-12

---

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]

📝 Walkthrough

Walkthrough

A new feature gate, KMSEncryption, was added and registered while KMSEncryptionProvider’s enablement was narrowed. Feature-gate entries were added or adjusted across payload manifests and the generated feature-gated CRD manifest. The APIServer CRD schema had the kms subtree and its associated x-kubernetes-validations removed. New KMSEncryption test YAMLs were added and a prior KMSEncryptionProvider test file was removed. OpenAPI documentation was updated (PowerVSPlatformSpec values, PacemakerClusterNodeStatus renames/list-key changes, fencing agent enum/descriptions, and minor wording edits). features.md was updated to rename KMSEncryptionProvider → KMSEncryption.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description check	✅ Passed	The description is directly related to the changeset, explaining the relaxation of KMS validation to allow nil KMSConfig when encryption type is KMS, and introducing the KMSEncryption feature gate to control this behavior.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Title check	✅ Passed	The title 'OCPBUGS-68343: Introduce KMSEncryption feature gate' clearly summarizes the main change—introducing a new KMSEncryption feature gate alongside relaxing KMS validation. It is concise, specific, and directly reflects the primary objective of the changeset.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

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

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
⚪	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Nil KMS handling: The validation change explicitly allows type: KMS with missing kms config, which may lead to downstream runtime failures unless all consumers/operators gracefully handle a nil kms configuration. Referred Code // +openshift:validation:FeatureGateAwareXValidation:featureGate=KMSEncryptionProvider,rule="self.type != 'KMS' ? !has(self.kms) : true",message="kms config is forbidden when encryption type is not KMS" // +union Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Relaxed validation risk: By relaxing schema validation to allow type: KMS without kms, the API may accept configurations that are not actionable unless additional server-side/controller validation ensures secure defaults or rejects invalid states later. Referred Code - message: kms config is forbidden when encryption type is not KMS rule: 'self.type != ''KMS'' ? !has(self.kms) : true' Learn more about managing compliance generic rules or creating your own custom rules
Update

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Strengthen validation for KMS configuration Strengthen the KMS configuration validation. The current rule allows an empty kms: {} object; update it to ensure that if kms is present, its type field is also required. config/v1/types_apiserver.go [178] -// +openshift:validation:FeatureGateAwareXValidation:featureGate=KMSEncryptionProvider,rule="self.type != 'KMS' ? !has(self.kms) : true",message="kms config is forbidden when encryption type is not KMS" +// +openshift:validation:FeatureGateAwareXValidation:featureGate=KMSEncryptionProvider,rule="self.type != 'KMS' ? !has(self.kms) : (has(self.kms) ? has(self.kms.type) : true)",message="kms config is forbidden when encryption type is not KMS, and if present, kms.type is required" Apply / Chat Suggestion importance[1-10]: 8 __ Why: This suggestion correctly identifies a weakness in the new validation rule that could allow an invalid kms: {} configuration and proposes a more robust rule to prevent it, improving correctness.	Medium
	Explicitly assert nil KMS config In the test case Should be able to create with KMS type and nil kms config, explicitly assert kms: null in the expected output to make the test's intent clearer. config/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml [65-72] expected: | apiVersion: config.openshift.io/v1 kind: APIServer spec: audit: profile: Default encryption: type: KMS + kms: null Apply / Chat Suggestion importance[1-10]: 5 __ Why: The suggestion improves test clarity by explicitly asserting that the kms field should be null, making the test case more precise and readable, though the current test is also functionally correct.	Low
High-level	Clarify the behavior of nil KMSConfig Update the API documentation for APIServerEncryption to explain the meaning and expected system behavior when type is KMS but the kms configuration block is nil. This will improve clarity for API consumers. Examples: config/v1/types_apiserver.go [180-193] type APIServerEncryption struct { // type defines what encryption type should be used to encrypt resources at the datastore layer. // When this field is unset (i.e. when it is set to the empty string), identity is implied. // The behavior of unset can and will change over time. Even if encryption is enabled by default, // the meaning of unset may change to a different encryption type based on changes in best practices. // // When encryption is enabled, all sensitive resources shipped with the platform are encrypted. // This list of sensitive resources can and will change over time. The current authoritative list is: // // 1. secrets ... (clipped 4 lines) Solution Walkthrough: Before: // config/v1/types_apiserver.go // APIServerEncryption is used to encrypt sensitive resources on the cluster. // +openshift:validation: ... rule="... self.type == 'KMS' ? has(self.kms) : !has(self.kms)" ... type APIServerEncryption struct { Type EncryptionType `json:"type,omitempty"` // kms is the configuration used to encrypt secret data. // This field should be set if and only if the `encryption.type` is `KMS`. // When `encryption.type` is `KMS`, this field is required. // +optional KMS *KMSConfig `json:"kms,omitempty"` } After: // config/v1/types_apiserver.go // APIServerEncryption is used to encrypt sensitive resources on the cluster. // +openshift:validation: ... rule="self.type != 'KMS' ? !has(self.kms) : true" ... type APIServerEncryption struct { Type EncryptionType `json:"type,omitempty"` // kms is the configuration used to encrypt secret data. // This field must be specified if `encryption.type` is `KMS` and a specific // provider (like AWS, GCP, etc.) is to be configured. // If `encryption.type` is `KMS` and this field is nil, it implies // [explanation of the behavior, e.g., an external controller will provide the config]. // +optional KMS *KMSConfig `json:"kms,omitempty"` } Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies that the PR introduces a new valid API state without documenting its semantic meaning, which is a significant omission for API clarity and maintainability.	Medium
Update

[ardaguclu]

/cc @benluddy @bertinatto @p0lyn0mial

[p0lyn0mial]

/lgtm

[p0lyn0mial]

From what I understand, this field will be deprecated in the future anyway.
For KMS v1, we don’t need it at all.

To make the backport easier, we would like to relax the validation only.

Considering that there hasn’t been any implementation added for this field, the changes look good to me.

[ardaguclu]

Agreed. Thanks for review.

[JoelSpeed]

Do we expect in the future to have or require this KMS field?

The field is tech preview, so we don't need to deprecate it, we could remove it if we think that it won't be needed in the long term at all.

If we do need it in the long term, is there a future where it is acceptable that the KMS field is an optional union member? Or are you expecting in this case that the KMS field would be required when type is KMS?

[ardaguclu]

It is hard to answer these questions for sure, since we actively discuss the design. But in my opinion, it is likely that we would mark this field (or another field like kmsv2 by tombstoning kmsConfig) as required.

[JoelSpeed]

I would like to make sure, that if we don't need this field, it is not promoted to the default feature set until it is implemented

Which gate are you intending to promote here? Can the required parts be under one gate and the union member/union validation be under a separate gate?

[p0lyn0mial]

also, with this new approach, we would not need to change or backport any changes to openshift/client-go, right?

[JoelSpeed]

There's no client-go changes for this no, I think this LGTM now, we can merge this, promote the new KMSEncryption gate and then come back to the other gate when we do the fuller implementation later

[ardaguclu]

promote the new KMSEncryption gate

With respect to this, what should I do?

[JoelSpeed]

Normally, we would require 5 E2E tests reporting into component readiness gated on this feature gate [OCPFeatureGate:KMSEncryption], are you able to build some tests for this part of the feature?

[ardaguclu]

Currently we are actively working on deploying kms plugin on OCP for our e2e tests (openshift/release#73750). But it is not ready yet.

Can we backport this PR to 4.21 before e2e tests?. We'll need to vendor library-go with openshift/api, after that apiserver operators need to be vendored with library-go and openshift/api to run E2E tests.

[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

[ardaguclu]

I'm cancelling this lgtm to not trigger CI jobs, until API reviewers review this PR
/lgtm cancel
/cc @JoelSpeed

[openshift-ci-robot]

@ardaguclu: This pull request references CNTRLPLANE-2241 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

User description

As we discussed in openshift/enhancements#1900. We need to allow nil KMSConfig, when encryption type is set to KMS.

This PR introduces new KMSEncryption feature gate to exclude KMSConfig which is only enabled when KMSEncryptionProvider feature gate.

---

PR Type

Enhancement

---

Description

• Relax KMS validation rule to allow nil KMSConfig when encryption type is KMS

• Update validation message to only forbid kms config for non-KMS encryption types

• Add test case verifying KMS type with nil kms config is accepted

• Update all CRD manifests and generated files with new validation rule

---

Diagram Walkthrough

flowchart LR
 A["Old Validation Rule"] -->|"Requires kms config<br/>when type=KMS"| B["Strict Validation"]
 C["New Validation Rule"] -->|"Allows nil kms config<br/>when type=KMS"| D["Relaxed Validation"]
 B -->|"PR Changes"| D
 E["Test Case Added"] -->|"Validates KMS type<br/>with nil config"| D

Loading

File Walkthrough

	Relevant files
Enhancement	1 files types_apiserver.go Update KMS validation rule to allow nil config                      +1/-1
Tests	1 files KMSEncryptionProvider.yaml Add test for KMS type with nil kms config                                +10/-4
Configuration changes	7 files 0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml Update KMS validation in CustomNoUpgrade CRD manifest        +2/-4      0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml Update KMS validation in DevPreviewNoUpgrade CRD manifest +2/-4      0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml Update KMS validation in TechPreviewNoUpgrade CRD manifest +2/-4      KMSEncryptionProvider.yaml Update KMS validation in featuregated CRD manifest              +2/-4      0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml Update KMS validation in payload CustomNoUpgrade CRD          +2/-4      0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml Update KMS validation in payload DevPreviewNoUpgrade CRD  +2/-4      0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml Update KMS validation in payload TechPreviewNoUpgrade CRD +2/-4
Documentation	1 files openapi.json Update OpenAPI schema with validation and documentation changes +17/-12

---

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.

[JoelSpeed]

/lgtm

@p0lyn0mial @ardaguclu provided you are both happy, I'll leave the verified label to you

[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

[p0lyn0mial]

won't this flag also be on for TP ? If yes, will it allow for setting an empty KMSConfig ?

[ardaguclu]

@JoelSpeed on TP enabled cluster, won't this old feature gate be enabled too?. Won't this create conflicting behavior? i.e. KMSEncryption allows simply KMS enum but KMSEncryptionProvider does not allow it.

[p0lyn0mial]

@JoelSpeed is there a way to write an integration / unit test that would enable these two FG ?

[ardaguclu]

or each feature gate needs to be explicitly enabled on the cluster. So that we would just assume that user will enable KMSEncryption but not KMSEncryptionProvider

[JoelSpeed]

Currently yes, on a TP cluster you would see the old/existing behaviour. If you promoted the feature KMSEncyption to default, you would not be able to set the KMS field because it wouldn't exist.

If you are concerned about the interactions between them/testing both, you can either disable KMSEncryptionProvider from TechPreview and move it back to just DevPreview, or we can set up tests that require both gates, and just one gate, or, one gate that not the other. In the test files where you specify the gates, prefix with - to negate the inclusion

[JoelSpeed]

Won't this create conflicting behavior? i.e. KMSEncryption allows simply KMS enum but KMSEncryptionProvider does not allow it.

You'd currently observe just the behaviour of the KMSEncryptionProvider feature gate, as it's a superset of the new gate.

[ardaguclu]

I think, we are both fine to moving KMSEncryptionProvider to DevPreview.

[ardaguclu]

I've moved KMSEncryptionProvider FG to DevPreview.

[JoelSpeed]

This was wrong, you didn't need line 6 here, please add this file back without L6

[ardaguclu]

Added back.

[ardaguclu]

CI is in good shape. Would you please have a look at when you have a chance?

[openshift-ci]

@ardaguclu: The following tests 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/verify-crd-schema	45ee221	link	true	/test verify-crd-schema
ci/prow/verify-crdify	45ee221	link	true	/test verify-crdify

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-ci-robot]

@ardaguclu: This pull request references Jira Issue OCPBUGS-68343, which is invalid:

• expected the bug to target the "4.22.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:

User description

As we discussed in openshift/enhancements#1900. We need to allow nil KMSConfig, when encryption type is set to KMS.

This PR introduces new KMSEncryption feature gate to exclude KMSConfig which is only enabled when KMSEncryptionProvider feature gate.

---

PR Type

Enhancement

---

Description

• Relax KMS validation rule to allow nil KMSConfig when encryption type is KMS

• Update validation message to only forbid kms config for non-KMS encryption types

• Add test case verifying KMS type with nil kms config is accepted

• Update all CRD manifests and generated files with new validation rule

---

Diagram Walkthrough

flowchart LR
 A["Old Validation Rule"] -->|"Requires kms config<br/>when type=KMS"| B["Strict Validation"]
 C["New Validation Rule"] -->|"Allows nil kms config<br/>when type=KMS"| D["Relaxed Validation"]
 B -->|"PR Changes"| D
 E["Test Case Added"] -->|"Validates KMS type<br/>with nil config"| D

Loading

File Walkthrough

	Relevant files
Enhancement	1 files types_apiserver.go Update KMS validation rule to allow nil config                      +1/-1
Tests	1 files KMSEncryptionProvider.yaml Add test for KMS type with nil kms config                                +10/-4
Configuration changes	7 files 0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml Update KMS validation in CustomNoUpgrade CRD manifest        +2/-4      0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml Update KMS validation in DevPreviewNoUpgrade CRD manifest +2/-4      0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml Update KMS validation in TechPreviewNoUpgrade CRD manifest +2/-4      KMSEncryptionProvider.yaml Update KMS validation in featuregated CRD manifest              +2/-4      0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml Update KMS validation in payload CustomNoUpgrade CRD          +2/-4      0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml Update KMS validation in payload DevPreviewNoUpgrade CRD  +2/-4      0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml Update KMS validation in payload TechPreviewNoUpgrade CRD +2/-4
Documentation	1 files openapi.json Update OpenAPI schema with validation and documentation changes +17/-12

---

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.

[ardaguclu]

/jira refresh

[openshift-ci-robot]

@ardaguclu: This pull request references Jira Issue OCPBUGS-68343, 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 (4.22.0) matches configured target version for branch (4.22.0)
• bug is in the state New, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @gangwgr

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.

[JoelSpeed]

/lgtm
/override ci/prow/verify-crdify
/override ci/prow/verify-crd-schema

[openshift-ci]

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

Details

In response to this:

/lgtm
/override ci/prow/verify-crdify
/override ci/prow/verify-crd-schema

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.

[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: JoelSpeed, p0lyn0mial

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]

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