CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers by ardaguclu · Pull Request #2086 · openshift/library-go

ardaguclu · 2026-01-23T07:39:37Z

This PR adds the implementation proposed in openshift/enhancements#1900.

This PR introduces KMS as a new mode in encryption controllers to be functioning along side with the other modes. Basically, the idea is to track the KMS configuration to detect any configuration changes. So that key_controller can create new Secret to initiate migration. KMS Secret will not contain any confidential data. It will simply store the KMS configuration.

For Tech Preview v1, we will only support static unix domain socket (i.e. unix:///var/run/kmsplugin/kms.sock). Consequently, in this version, we don't support KMS -> KMS migrations.

Ref: Previous attemps:

Notes:

The changes here will be backported to 4.21
Substantial portion of the changed lines are unit and integration tests.

openshift-ci-robot · 2026-01-23T07:39:42Z

@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:

This PR adds the implementation proposed in openshift/enhancements#1900.

This PR introduces KMS as a new mode in encryption controllers to be functioning along side with the other modes. Basically, the idea is to track the KMS configuration to detect any configuration changes. So that key_controller can create new Secret to initiate migration. KMS Secret will not contain any confidential data. It will simply store the KMS configuration.

For Tech Preview v1, we will only support static unix domain socket (i.e. unix:///var/run/kmsplugin/kms.sock). Consequently, in this version, we don't support KMS -> KMS migrations.

Ref: Previous attemps:

NO-JIRA: Introduce KMS encryption mode into encryption controllers #2045

API-1844: KMS Encryption Provider #1876

Notes:

The changes here will be backported to 4.21

Most of the changes are obsessively added 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 · 2026-01-23T07:42:21Z

@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:

This PR adds the implementation proposed in openshift/enhancements#1900.

This PR introduces KMS as a new mode in encryption controllers to be functioning along side with the other modes. Basically, the idea is to track the KMS configuration to detect any configuration changes. So that key_controller can create new Secret to initiate migration. KMS Secret will not contain any confidential data. It will simply store the KMS configuration.

For Tech Preview v1, we will only support static unix domain socket (i.e. unix:///var/run/kmsplugin/kms.sock). Consequently, in this version, we don't support KMS -> KMS migrations.

Ref: Previous attemps:

NO-JIRA: Introduce KMS encryption mode into encryption controllers #2045

API-1844: KMS Encryption Provider #1876

Notes:

The changes here will be backported to 4.21

Substantial portion of the changed lines are 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 · 2026-01-23T08:56:35Z

@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:

This PR adds the implementation proposed in openshift/enhancements#1900.

This PR introduces KMS as a new mode in encryption controllers to be functioning along side with the other modes. Basically, the idea is to track the KMS configuration to detect any configuration changes. So that key_controller can create new Secret to initiate migration. KMS Secret will not contain any confidential data. It will simply store the KMS configuration.

For Tech Preview v1, we will only support static unix domain socket (i.e. unix:///var/run/kmsplugin/kms.sock). Consequently, in this version, we don't support KMS -> KMS migrations.

Ref: Previous attemps:

NO-JIRA: Introduce KMS encryption mode into encryption controllers #2045

API-1844: KMS Encryption Provider #1876

Notes:

The changes here will be backported to 4.21

Substantial portion of the changed lines are unit and integration 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.

ardaguclu · 2026-01-23T09:24:27Z

Fake imports;

ardaguclu · 2026-01-27T07:43:02Z

/hold
These PRs are prerequisite of this;

OCPBUGS-68343: Bump openshift/api to get new KMS FG #2091 -- conceptually be based on the new feature gate (Rebased)
NO-JIRA: Enable test-e2e-encryption #2087 -- to be able to run integration tests (Rebased)

ardaguclu · 2026-01-27T15:54:14Z

/uncc @dgrisonnet
/cc @benluddy @bertinatto @p0lyn0mial

pkg/operator/encryption/crypto/keys.go

pkg/operator/encryption/kms/kms.go

pkg/operator/encryption/encryptionconfig/config.go

pkg/operator/encryption/kms/kms.go

pkg/operator/encryption/encryptionconfig/config.go

pkg/operator/encryption/kms/kms.go

pkg/operator/encryption/crypto/keys.go

p0lyn0mial · 2026-02-09T13:19:34Z

pkg/operator/encryption/encryptionconfig/config.go

+				// Since in v1 we don't support kms -> kms migrations, we can use empty key.
+				// Because we don't need to compare secrets to detect change.
+				secret := crypto.ModeToNewKeyFunc[state.KMS]()
+				keyId := strings.Split(provider.KMS.Name, "-")[0]


I’m still wondering about encapsulation here.
I think other parts of the code won’t even be aware that the name has changed.

Only the code in encryptionconfig/config.go will encode and decode the new name, right?

Do we need to ensure that the name doesn’t already contain "-"?
For simplicity, we could add a comment in the key generation function describing this requirement.

Only the code in encryptionconfig/config.go will encode and decode the new name, right?

That is correct. Rest of the code only deals with KeyState. They do not even know about the details of EncryptionConfiguration.

Do we need to ensure that the name doesn’t already contain "-"?

Kube-apiserver already fails, if it encounters a provider name without -. Because uniqueness has broken.

For simplicity, we could add a comment in the key generation function describing this requirement.

I've added a comment about the reasons behind this provider name generation mechanism. Please let me know your thoughts. Thanks.

benluddy · 2026-02-10T22:11:19Z

pkg/operator/encryption/encryptionconfig/config.go

+func getKeyIDFromProviderName(providerName string) string {
+	// We just need to obtain the keyID to find our backed secret
+	// e.g. "1-secrets"
+	return strings.Split(providerName, "-")[0]


How should this handle an unexpected provider name?

Although it may not be possible, it is better to handle the invalid provider name gracefully. I've updated the code. Please let me know your thoughts.

benluddy · 2026-02-10T22:16:39Z

pkg/operator/encryption/encryptionconfig/config.go

 				},
 			})
+		case state.KMS:
+			// In order to preserve the uniqueness, we should insert resource name


OK, "kms v2 providers name must always be unique across all kms providers (v1 and v2)":

https://github.com/kubernetes/kubernetes/blob/870e2928bc1d9a48a8ef75289ea57ec6cdeb5cb3/staging/src/k8s.io/apiserver/pkg/apis/apiserver/validation/validation_encryption.go#L438-L444

Are there going to be side effects from this naming scheme visible in things like metric labels?

All the metrics that is about provider_name will be affected https://github.com/kubernetes/kubernetes/blob/90a76aaa9afbe9cdb3df5f0a4356018b6637648b/staging/src/k8s.io/apiserver/pkg/storage/value/encrypt/envelope/metrics/metrics.go#L169.

benluddy · 2026-02-10T22:21:25Z

pkg/operator/encryption/encryptionconfig/config.go

+func createKMSProviderName(keyID, resource string) string {
+	// Ideally we should have used keyId simply in kms provider name.
+	// However, this is an upstream constraint that every provider name must be unique.
+	// To maintain uniqueness while still allowing access to the keyId, we generate provider name in this format.


OK, this is at least less strange than smuggling identity names in phony AES-GCM provider configs. Later, I would be interested in coming up with alternatives that let the controllers correlate provider configs to their source secret without smuggling.

I agree with you. It was error-prone and not nice. Since now we carry KMSConfigurations in backed Secrets, I think we won't need to carry anything in provider_names.

benluddy · 2026-02-10T22:29:29Z

pkg/operator/encryption/controllers/key_controller.go

+		// Moreover, we don't trigger new key when external reason is changed.
+		// Because it would lead to duplicate providers which is not allowed.


IIUC, even if we did roll out a new encryption config in response to the "reason" update, we're not even capable of triggering a KEK rotation unless a specific provider happened to expose that capability independently.

Good point. That is correct.

benluddy · 2026-02-10T22:36:21Z

pkg/operator/encryption/kms/helpers.go

+const (
+	DefaultEndpoint = "unix:///var/run/kmsplugin/kms.sock"
+	DefaultTimeout  = 10 * time.Second
+)


Is there a real need to export these constants? IMO, duplicating the values in tests is good because it requires that changes in observable behavior are accompanied by changes to test expectations. And other code (doing related things like setting up volume mounts) should be observing effective values rather than using hardcoded defaults.

The only reason is to be accessed by key_controller. If we move these constants in there, we don't need to export them.

could we just inline these in key_controller?

ardaguclu · 2026-02-16T10:58:43Z

cluster-authentication-operator e2e tests passed: https://prow.ci.openshift.org/view/gs/test-platform-results/pr-logs/pull/openshift_cluster-authentication-operator/837/pull-ci-openshift-cluster-authentication-operator-master-e2e-gcp-operator-encryption-kms/2023275986719608832
cluster-kube-apiserver-operator e2e tests passed: https://prow.ci.openshift.org/view/gs/test-platform-results/pr-logs/pull/openshift_cluster-kube-apiserver-operator/2033/pull-ci-openshift-cluster-kube-apiserver-operator-main-e2e-gcp-operator-encryption-kms/2021125688223862784
cluster-openshift-apiserver-operator e2e tests passed: https://prow.ci.openshift.org/view/gs/test-platform-results/pr-logs/pull/openshift_cluster-openshift-apiserver-operator/647/pull-ci-openshift-cluster-openshift-apiserver-operator-main-e2e-gcp-operator-encryption-kms/2023391453706719232

p0lyn0mial · 2026-02-16T10:25:04Z

pkg/operator/encryption/controllers/key_controller.go

+	if currentMode == state.KMS {
+		ks.KMSConfiguration = &apiserverv1.KMSConfiguration{
+			APIVersion: "v2",
+			Name:       fmt.Sprintf("%d", keyID), // this will be updated by inserting resource name


given that the name will be changed only in the EncryptionConfiguration and will not be visible to the KeyState, is this comment still relevant?

maybe we should add a comment about the expected key format, which must include the keyID (at least for now)?

Comment is not relevant anymore. I've removed it.

pkg/operator/encryption/encryptionconfig/config.go

p0lyn0mial · 2026-02-16T11:25:51Z

pkg/operator/encryption/encryptionconfig/config.go

+				ks = state.KeyState{
+					Key: apiserverconfigv1.Key{
+						Name: keyId,
+						// Since in v1 we don't support kms -> kms migrations, we can use empty key.


Not sure if I understand this comment.

For KMS the Secret doesn't matter and can/will always be empty - because the actual encryption key material is in the external KMS instance.

In v2, we'll have to compare this field (or KMSConfiguration annotation) to detect configurational changes. But it sounds like this comment creates confusions. So I've removed it.

pkg/operator/encryption/encryptionconfig/config.go

pkg/operator/encryption/controllers/state_controller_test.go

pkg/operator/encryption/encryptionconfig/config_test.go

test/e2e-encryption/encryption_test.go

pkg/operator/encryption/controllers/key_controller_test.go

ardaguclu · 2026-02-17T08:10:41Z

Unrelated?
/test unit

p0lyn0mial · 2026-02-17T11:51:43Z

pkg/operator/encryption/encryptionconfig/config.go

+func getKeyIDFromProviderName(providerName string) (string, error) {
+	// We just need to obtain the keyID to find our backed secret
+	// e.g. "1_secrets"
+	parsed := strings.Split(providerName, "_")


should we use strings.SplitN ?

p0lyn0mial · 2026-02-17T11:53:01Z

pkg/operator/encryption/testing/helpers.go

+	secret := CreateEncryptionKeySecretWithRawKeyWithMode(targetNS, grs, keyID, emptyKey, "KMS")
+	kmsConfig := &apiserverconfigv1.KMSConfiguration{
+		APIVersion: "v2",
+		Name:       fmt.Sprintf("%d_%s", keyID, grs[0].Resource),


shouldn't this be fmt.Sprintf("%d", keyID) ?
the resource suffix is added later.

p0lyn0mial · 2026-02-17T11:54:53Z

pkg/operator/encryption/encryptionconfig/config.go

 			})
+		case state.KMS:
+			// In order to preserve the uniqueness, we should insert resource name
+			kmsCopy := key.KMSConfiguration.DeepCopy()


should we check key.KMSConfiguration for nil ?

Although this is not possible, it makes sense gracefully handling the empty KMSConfiguration by skipping it with a message. Please let me know your thoughts.

yes, that would match the existing pattern. good idea.

p0lyn0mial · 2026-02-17T11:56:37Z

pkg/operator/encryption/secrets/secrets.go

 	}

+	if ks.KMSConfiguration != nil {
+		ks, err := json.Marshal(ks.KMSConfiguration)


nit: ks shadows the outer ks, we could rename to ksJSON

p0lyn0mial · 2026-02-17T13:02:46Z

pkg/operator/encryption/encryptionconfig/config.go

 			})
 		case state.KMS:
+			if key.KMSConfiguration == nil {
+				klog.Infof("skipping key %s in KMS mode as its KMSConfiguration is nil", key.Key.Name)


should we add resource and index too?

I've added resource name in the log.

Index is not the index in EncryptionConfiguration providers. It is an index in the Backed Secrets. We have keyID already as discriminator. Would you still want me to insert index name?

p0lyn0mial · 2026-02-17T13:14:38Z

trying to find the test test failed:

https://prow.ci.openshift.org/view/gs/test-platform-results/pr-logs/pull/openshift_library-go/2086/pull-ci-openshift-library-go-master-unit/2023733071903199232

vs

https://prow.ci.openshift.org/view/gs/test-platform-results/pr-logs/pull/openshift_library-go/2086/pull-ci-openshift-library-go-master-unit/2023671487558324224

ardaguclu · 2026-02-17T14:00:22Z

All tests pass on my local. According to the junit results, all the tests passed in the CI jobs too https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/test-platform-results/pr-logs/pull/openshift_library-go/2086/pull-ci-openshift-library-go-master-unit/2023755244520869888/artifacts/test/artifacts/junit_report.xml. It looks like a transient failure;
/test unit

p0lyn0mial · 2026-02-18T07:35:10Z

pkg/operator/encryption/encryptionconfig/config.go

 	return providers
 }
+
+func createKMSProviderName(keyID, resource string) string {


just a comment: as of today there a no restrictions on length for the provider name. the only restriction i found is that we are not allowed to use :

pkg/operator/encryption/controllers/key_controller.go

bertinatto · 2026-02-19T20:30:27Z

pkg/operator/encryption/state/types.go

 	AESGCM    Mode = "aesgcm"
 	SecretBox Mode = "secretbox" // available from the first release, see defaultMode below
 	Identity  Mode = "identity"  // available from the first release, see defaultMode below
+	KMS       Mode = "KMS"       // only supports KMS v2


nit: all the others are lowercase ("KMS")

Unfortunately this definition comes from https://github.com/openshift/api/blob/43090db3afe48e7dff0f6e39a866474d15cd0db5/config/v1/types_apiserver.go#L234 API. I agree that it should be lowercase, but we can't change it without API changes.

bertinatto · 2026-02-19T20:53:29Z

pkg/operator/encryption/secrets/secrets.go

 	keyMode := state.Mode(s.Annotations[encryptionSecretMode])
 	switch keyMode {
-	case state.AESCBC, state.AESGCM, state.SecretBox, state.Identity:
+	case state.AESCBC, state.AESGCM, state.SecretBox, state.Identity, state.KMS:


Do you also need to add a check to test if keyMode is KMS and key.KMSConfiguration is nil?

This function (i.e. ToKeyState) is pure conversion from Secret to KeyState without any logic. The caller checks the emptiness of KMSConfiguration in https://github.com/openshift/library-go/pull/2086/changes#diff-9aecf0d61d4bb32f2825a75a37e02e2c1b612c000427f3f576d42853ac8d23aeR212-R215 (and silently ignores it). In my opinion, it would be better to leave the decision to user of KMSConfiguration (i.e. stateToProviders).

We can add a check in here though. Once we add it, since ToKeyState is used by all controllers, any misconfiguration (KMS mode is enabled, but somehow KMSConfiguration is nil) will cause the failure of the controllers. On the other hand, this condition must not happen anyway. I'd like to hear opinions from @p0lyn0mial

We can be defensive and add additional checks. What kind of checks would we like to add ?

Perhaps something like this;

case state.KMS: if key.KMSConfiguration == nil { return state.KeyState{}, fmt.Errorf("KMSConfiguration can not be nil, when mode is KMS") } key.Mode = keyMode

Updated. Please let me know your opinions.

bertinatto

/lgtm

openshift-ci · 2026-02-23T13:39:49Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ardaguclu, bertinatto

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:

~~pkg/operator/encryption/OWNERS~~ [bertinatto]
~~test/e2e-encryption/OWNERS~~ [bertinatto]

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

openshift-ci · 2026-02-23T14:55:17Z

@ardaguclu: 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-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Jan 23, 2026

openshift-ci bot requested review from dgrisonnet and p0lyn0mial January 23, 2026 07:39

ardaguclu force-pushed the kms-mode branch from eb55a0f to 0dcacb4 Compare January 23, 2026 07:48

ardaguclu changed the title ~~CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers~~ WIP: CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers Jan 23, 2026

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 Jan 23, 2026

ardaguclu force-pushed the kms-mode branch from 0dcacb4 to a7cfa5f Compare January 23, 2026 08:50

This was referenced Jan 23, 2026

WIP: Fake vendor library-go openshift/cluster-kube-apiserver-operator#2013

Closed

WIP: Fake vendor library-go openshift/cluster-openshift-apiserver-operator#639

Closed

WIP: Fake vendor library-go openshift/cluster-authentication-operator#824

Closed

ardaguclu changed the title ~~WIP: CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers~~ CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers Jan 23, 2026

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 Jan 23, 2026

ardaguclu changed the title ~~CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers~~ WIP: CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers Jan 23, 2026

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 Jan 23, 2026

ardaguclu force-pushed the kms-mode branch 2 times, most recently from 377c3cb to 0b007f9 Compare January 27, 2026 07:41

ardaguclu changed the title ~~WIP: CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers~~ CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers Jan 27, 2026

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 Jan 27, 2026

openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jan 27, 2026

ardaguclu force-pushed the kms-mode branch from 0b007f9 to 99f27e5 Compare January 27, 2026 08:18

openshift-ci bot requested review from benluddy and bertinatto and removed request for dgrisonnet January 27, 2026 15:54

bertinatto reviewed Jan 27, 2026

View reviewed changes

p0lyn0mial reviewed Feb 9, 2026

View reviewed changes

pkg/operator/encryption/crypto/keys.go Outdated Show resolved Hide resolved

p0lyn0mial reviewed Feb 9, 2026

View reviewed changes

ardaguclu force-pushed the kms-mode branch from b8208c8 to 9351ccf Compare February 10, 2026 06:33

benluddy reviewed Feb 10, 2026

View reviewed changes

p0lyn0mial reviewed Feb 16, 2026

View reviewed changes

ardaguclu force-pushed the kms-mode branch 2 times, most recently from b19c772 to 5a7a2b2 Compare February 17, 2026 07:34

p0lyn0mial reviewed Feb 17, 2026

View reviewed changes

p0lyn0mial reviewed Feb 18, 2026

View reviewed changes

bertinatto reviewed Feb 19, 2026

View reviewed changes

Add KMS encryption mode into library-go encryption controllers

d26ec6a

ardaguclu force-pushed the kms-mode branch from e603596 to d26ec6a Compare February 23, 2026 06:07

Return error when kms mode and empty KMSConfiguration

2530c06

bertinatto reviewed Feb 23, 2026

View reviewed changes

openshift-ci bot assigned bertinatto Feb 23, 2026

openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Feb 23, 2026

openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 23, 2026

openshift-merge-bot bot merged commit 7b234b4 into openshift:master Feb 23, 2026
5 checks passed

ardaguclu deleted the kms-mode branch February 23, 2026 14:59

		// Moreover, we don't trigger new key when external reason is changed.
		// Because it would lead to duplicate providers which is not allowed.

Conversation

ardaguclu commented Jan 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci-robot commented Jan 23, 2026 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci-robot commented Jan 23, 2026 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci-robot commented Jan 23, 2026 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ardaguclu commented Jan 23, 2026

Uh oh!

ardaguclu commented Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ardaguclu commented Jan 27, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ardaguclu commented Feb 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ardaguclu commented Feb 17, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ardaguclu commented Jan 23, 2026 •

edited

Loading

openshift-ci-robot commented Jan 23, 2026 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Jan 23, 2026 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Jan 23, 2026 •

edited by openshift-ci bot

Loading

ardaguclu commented Jan 27, 2026 •

edited

Loading

ardaguclu commented Feb 16, 2026 •

edited

Loading

bertinatto Feb 19, 2026 •

edited

Loading