HIVE-2302, HIVE-2644: Pass metadata.json through opaquely #2729

2uasimojo · 2025-08-05T22:16:01Z

Previously any time installer added a field to metadata.json, we would need to evaluate and possibly add a bespoke field and code path for it to make sure it was supplied to the destroyer at deprovision time.

With this change, we're offloading metadata.json verbatim (except in some cases we have to scrub/replace credentials fields -- see HIVE-2804 / #2612) to a new Secret in the ClusterDeployment's namespace, referenced from a new field: ClusterDeployment.Spec.ClusterMetadata.MetadataJSONSecretRef.

For legacy clusters -- those created before this change -- we attempt to retrofit the new Secret based on the legacy fields. This is best effort and may not always work.

This change then adds a new generic destroyer via the (existing) hiveutil deprovision command that consumes this metadata.json to deprovision the cluster.

This new behavior is the default, but we also include an escape hatch to run the platform-specific legacy destroyer by setting the following annotation on the ClusterDeployment:

hive.openshift.io/legacy-deprovision: "true"

openshift-ci-robot · 2025-08-05T22:16:05Z

@2uasimojo: This pull request references HIVE-2302 which is a valid jira issue.

In response to this:

Well, mostly.

Previously any time installer added a field to metadata.json, we would need to evaluate and possibly add a bespoke field and code path for it to make sure it was supplied to the destroyer at deprovision time.

With this change, we're instead offloading it verbatim to a new Secret in the ClusterDeployment's namespace, referenced from a new field: ClusterDeployment.Spec.ClusterMetadata.MetadataJSONSecretRef.

Instead of building the installer's ClusterMetadata structure for the destroyer with individual fields from the CD's ClusterMetadata, we're unmarshaling it directly from the contents of that Secret.

(Except in some cases we have to scrub/replace credentials fields -- see HIVE-2804 / #2612)

For legacy clusters -- those created before this change -- we attempt to retrofit the new Secret based on the legacy fields. This is best effort and may not always work. If this results in a hanging deprovision due to a missing field, the workaround is to modify the contents of the Secret to add it in; then kill the deprovision pod and the next attempt should pick up the changes. (If the result is a "successful" deprovision with leaked resources, the only workaround is to clean up the infra manually. Sorry.)

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 · 2025-08-05T22:16:06Z

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

openshift-ci-robot · 2025-08-05T22:16:09Z

@2uasimojo: This pull request references HIVE-2302 which is a valid jira issue.

In response to this:

Well, mostly.

Previously any time installer added a field to metadata.json, we would need to evaluate and possibly add a bespoke field and code path for it to make sure it was supplied to the destroyer at deprovision time.

With this change, we're instead offloading it verbatim to a new Secret in the ClusterDeployment's namespace, referenced from a new field: ClusterDeployment.Spec.ClusterMetadata.MetadataJSONSecretRef.

Instead of building the installer's ClusterMetadata structure for the destroyer with individual fields from the CD's ClusterMetadata, we're unmarshaling it directly from the contents of that Secret.

(Except in some cases we have to scrub/replace credentials fields -- see HIVE-2804 / #2612)

For legacy clusters -- those created before this change -- we attempt to retrofit the new Secret based on the legacy fields. This is best effort and may not always work. If this results in a hanging deprovision due to a missing field, the workaround is to modify the contents of the Secret to add it in; then kill the deprovision pod and the next attempt should pick up the changes. (If the result is a "successful" deprovision with leaked resources, the only workaround is to clean up the infra manually. Sorry.)

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 · 2025-08-05T22:16:17Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: 2uasimojo

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~OWNERS~~ [2uasimojo]

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

2uasimojo · 2025-08-05T22:16:55Z

TODO: Deprovisioner side

pkg/controller/clusterclaim/clusterclaim_controller.go

openshift-ci-robot · 2025-08-15T18:11:55Z

@2uasimojo: This pull request references HIVE-2302 which is a valid jira issue.

In response to this:

Well, mostly.

Previously any time installer added a field to metadata.json, we would need to evaluate and possibly add a bespoke field and code path for it to make sure it was supplied to the destroyer at deprovision time.

With this change, we're offloading metadata.json verbatim (except in some cases we have to scrub/replace credentials fields -- see HIVE-2804 / #2612) to a new Secret in the ClusterDeployment's namespace, referenced from a new field: ClusterDeployment.Spec.ClusterMetadata.MetadataJSONSecretRef.

For legacy clusters -- those created before this change -- we attempt to retrofit the new Secret based on the legacy fields. This is best effort and may not always work.

In the future (but not here!) instead of building the installer's ClusterMetadata structure for the destroyer with individual fields from the CD's ClusterMetadata, we'll unmarshal it directly from the contents of this Secret.

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 · 2025-08-15T18:11:58Z

@2uasimojo: This pull request references HIVE-2302 which is a valid jira issue.

In response to this:

Well, mostly.

Previously any time installer added a field to metadata.json, we would need to evaluate and possibly add a bespoke field and code path for it to make sure it was supplied to the destroyer at deprovision time.

With this change, we're offloading metadata.json verbatim (except in some cases we have to scrub/replace credentials fields -- see HIVE-2804 / #2612) to a new Secret in the ClusterDeployment's namespace, referenced from a new field: ClusterDeployment.Spec.ClusterMetadata.MetadataJSONSecretRef.

For legacy clusters -- those created before this change -- we attempt to retrofit the new Secret based on the legacy fields. This is best effort and may not always work.

In the future (but not here!) instead of building the installer's ClusterMetadata structure for the destroyer with individual fields from the CD's ClusterMetadata, we'll unmarshal it directly from the contents of this Secret.

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 · 2025-09-09T20:37:22Z

@2uasimojo: This pull request references HIVE-2302 which is a valid jira issue.

This pull request references HIVE-2644 which is a valid jira issue.

In response to this:

Well, mostly.

Previously any time installer added a field to metadata.json, we would need to evaluate and possibly add a bespoke field and code path for it to make sure it was supplied to the destroyer at deprovision time.

With this change, we're offloading metadata.json verbatim (except in some cases we have to scrub/replace credentials fields -- see HIVE-2804 / #2612) to a new Secret in the ClusterDeployment's namespace, referenced from a new field: ClusterDeployment.Spec.ClusterMetadata.MetadataJSONSecretRef.

For legacy clusters -- those created before this change -- we attempt to retrofit the new Secret based on the legacy fields. This is best effort and may not always work.

In the future (but not here!) instead of building the installer's ClusterMetadata structure for the destroyer with individual fields from the CD's ClusterMetadata, we'll unmarshal it directly from the contents of this Secret.

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 · 2025-09-09T20:39:22Z

@2uasimojo: This pull request references HIVE-2302 which is a valid jira issue.

This pull request references HIVE-2644 which is a valid jira issue.

In response to this:

Previously any time installer added a field to metadata.json, we would need to evaluate and possibly add a bespoke field and code path for it to make sure it was supplied to the destroyer at deprovision time.

With this change, we're offloading metadata.json verbatim (except in some cases we have to scrub/replace credentials fields -- see HIVE-2804 / #2612) to a new Secret in the ClusterDeployment's namespace, referenced from a new field: ClusterDeployment.Spec.ClusterMetadata.MetadataJSONSecretRef.

For legacy clusters -- those created before this change -- we attempt to retrofit the new Secret based on the legacy fields. This is best effort and may not always work.

This change then adds a new generic destroyer via the (existing) hiveutil deprovision command that consumes this metadata.json to deprovision the cluster.

This new behavior is the default, but we also include an escape hatch to run the platform-specific legacy destroyer by setting the following annotation on the ClusterDeployment:

hive.openshift.io/legacy-deprovision: "true"

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.

2uasimojo · 2025-09-09T21:52:15Z

/test e2e e2e-azure e2e-gcp e2e-vsphere e2e-openstack

🤞

2uasimojo · 2025-09-10T19:01:51Z

/test e2e-azure e2e-vsphere

2uasimojo · 2025-09-23T19:40:07Z

This is now rebased on HIVE-2908: Remove OVirt (RHV) #2746
VSphere (hopefully) remedied: metadata.json can be in one of two different shapes depending on pre- or post-zonal. We should now be accounting for both.

/test e2e-vsphere

2uasimojo · 2025-09-23T21:32:54Z

/hold for moar testings

codecov · 2025-09-23T22:05:31Z

Codecov Report

❌ Patch coverage is 18.94977% with 355 lines in your changes missing coverage. Please review.
✅ Project coverage is 50.20%. Comparing base (d17bd65) to head (de21622).

Files with missing lines	Patch %	Lines
.../clusterdeployment/clusterdeployment_controller.go	27.70%	100 Missing and 7 partials ⚠️
pkg/install/generate.go	18.18%	95 Missing and 4 partials ⚠️
contrib/pkg/deprovision/deprovision.go	0.00%	45 Missing ⚠️
pkg/clusterresource/builder.go	0.00%	18 Missing and 3 partials ⚠️
contrib/pkg/utils/vsphere/vsphere.go	0.00%	18 Missing ⚠️
contrib/pkg/createcluster/create.go	0.00%	11 Missing ⚠️
contrib/pkg/utils/nutanix/nutanix.go	0.00%	8 Missing ⚠️
pkg/installmanager/installmanager.go	22.22%	7 Missing ⚠️
contrib/pkg/deprovision/azure.go	0.00%	4 Missing ⚠️
contrib/pkg/deprovision/gcp.go	0.00%	4 Missing ⚠️
... and 14 more

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2729      +/-   ##
==========================================
- Coverage   50.45%   50.20%   -0.26%     
==========================================
  Files         284      284              
  Lines       33968    34243     +275     
==========================================
+ Hits        17140    17191      +51     
- Misses      15489    15703     +214     
- Partials     1339     1349      +10

Files with missing lines	Coverage Δ
pkg/constants/constants.go	`100.00% <ø> (ø)`
...lusterdeprovision/clusterdeprovision_controller.go	`53.40% <100.00%> (+0.17%)`	⬆️
pkg/controller/utils/logtagger.go	`100.00% <100.00%> (ø)`
.../v1/clusterdeployment_validating_admission_hook.go	`87.07% <100.00%> (+0.04%)`	⬆️
...shift/hive/apis/hive/v1/clusterdeployment_types.go	`0.00% <ø> (ø)`
...hift/hive/apis/hive/v1/clusterdeprovision_types.go	`0.00% <ø> (ø)`
contrib/pkg/deprovision/awstagdeprovision.go	`0.00% <0.00%> (ø)`
contrib/pkg/utils/aws/aws.go	`0.00% <0.00%> (ø)`
contrib/pkg/utils/azure/azure.go	`0.00% <0.00%> (ø)`
contrib/pkg/utils/gcp/gcp.go	`0.00% <0.00%> (ø)`
... and 20 more

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

2uasimojo · 2025-09-25T18:42:26Z

e2e and e2e-pool: actual tests succeeded; infra timeout flake
e2e-openstack looks like a flake where the openstack infra was ill
security was HIVE-2937, since resolved via HIVE-2937: revendor x/crypto for SNYK-GOLANG-GOLANGORGXCRYPTOSSHAGENT-12668891 #2755...

...so I think I'll just rebase to pick up that last one anyway.

...but I might as well wait until #2754 lands.

2uasimojo · 2025-10-01T19:16:59Z

/assign @dlom

2uasimojo · 2025-10-01T19:18:42Z

Legacy granny switch validated via #2759 ✓

2uasimojo · 2025-10-01T20:16:40Z

/retest hive-on-pull-request

2uasimojo · 2025-10-01T20:17:00Z

/retest hive-mce-26-on-pull-request

dlom · 2025-10-02T17:41:20Z

/retest hive-on-pull-request

dlom · 2025-10-02T17:42:30Z

/retest hive-mce-26-on-pull-request

openshift-ci · 2025-10-02T17:42:34Z

@dlom: The /retest command does not accept any targets.
The following commands are available to trigger required jobs:

/test coverage

/test e2e

/test e2e-azure

/test e2e-gcp

/test e2e-openstack

/test e2e-pool

/test e2e-vsphere

/test images

/test periodic-images

/test security

/test unit

/test verify

Use /test all to run all jobs.

In response to this:

/retest hive-mce-26-on-pull-request

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.

2uasimojo · 2025-10-02T18:42:17Z

/test e2e-openstack

Pre-actual-test IPI setup flake

2uasimojo · 2025-10-02T22:01:42Z

/test e2e-openstack

Same again

2uasimojo · 2025-10-03T14:37:50Z

/test e2e-openstack

Looks like provision timed out?

dlom · 2025-10-06T06:48:44Z

contrib/pkg/deprovision/deprovision.go

+			}
+
+			// TODO: Make a registry or interface for this
+			var ConfigureCreds func(client.Client)


I think this is fine, it's readable and makes sense

Ack. But it would jell with how we're getting the correct platform-specific destroyer from the installer -- see LL132 & 137 below. I don't mind leaving it for now though.

The most I would consider would be something like this:

type ConfigureCredsFn func(client.Client) ... var configureCreds ConfigureCredsFn

What does this gain? I still have to define the funcs with the full param spec, right?

dlom · 2025-10-06T06:52:54Z

contrib/pkg/deprovision/deprovision.go

+				// If env vars are unset, the destroyer will fail organically.
+				ConfigureCreds = func(c client.Client) {
+					nutanixutil.ConfigureCreds(c)
+					metadata.Nutanix.Username = os.Getenv(constants.NutanixUsernameEnvVar)
+					metadata.Nutanix.Password = os.Getenv(constants.NutanixPasswordEnvVar)
+				}


Suggested change

// If env vars are unset, the destroyer will fail organically.

ConfigureCreds = func(c client.Client) {

nutanixutil.ConfigureCreds(c)

metadata.Nutanix.Username = os.Getenv(constants.NutanixUsernameEnvVar)

metadata.Nutanix.Password = os.Getenv(constants.NutanixPasswordEnvVar)

}

// If env vars are unset, the destroyer will fail organically.

ConfigureCreds = nutanixutil.ConfigureCreds

metadata.Nutanix.Username = os.Getenv(constants.NutanixUsernameEnvVar)

metadata.Nutanix.Password = os.Getenv(constants.NutanixPasswordEnvVar)

I think you can just write it like this. The function is immediately invoked right below

That won't work without some refactoring, because ConfigureCreds is where those env vars get set, for both nutanix and vsphere.

Looking at it again, I think what makes sense is to pass the metadata into ConfigureCreds and set up the user/pass there. They are, after all, Creds that need to be Configured :)

My only objection to that is that I was trying to leave the legacy code path untouched as much as possible. Ultimately -- when we kill the legacy code path -- it'll be clean to do so; but in the meantime it would require me to either pass a dummy metadata is through or add a nil check condition in ConfigureCreds. The latter seems like the lesser evil. But I'm not sure it's worthwhile -- WDYT?

I think adding a metadata parameter and using a nil check to all of the ConfigureCreds implementations is a good compromise, especially if the line count is low (probably no more than +10 per file)

Done, via a separate commit in case we hate it :)

contrib/pkg/deprovision/deprovision.go

pkg/controller/clusterdeployment/clusterdeployment_controller.go

dlom · 2025-10-20T18:00:31Z

contrib/pkg/deprovision/deprovision.go

-			}
-
-			ConfigureCreds(c)
+			ConfigureCreds[platform](c, metadata)


huangmingxia · 2025-10-24T09:18:03Z

pkg/controller/clusterdeployment/clusterdeployment_controller.go

 			}
+			if mdjsr := cd.Spec.ClusterMetadata.MetadataJSONSecretRef; mdjsr != nil && mdjsr.Name != "" {
+				if err := r.addOwnershipToSecret(cd, cdLog, mdjsr.Name); err != nil {
+					return reconcile.Result{}, err


Hi @2uasimojo I have a question regarding the cleanup of the metadata.json Secret. Please correct me if I missed anything, thank you!

Currently, the OwnerReference of the metadata.json Secret is only set when the cluster installation succeeds. If the installation fails and the Secret has already been created, it has no OwnerReference and will remain in the cluster when the ClusterDeployment is deleted - it won’t be removed automatically.

Regarding the leftover Secret, there is a potential issue:
If an invalid metadata.json Secret already exists before the upgrade, the legacy retrofit path calls ensureMetadataJSONSecret() with forceUpdate=false. In this case, if the Secret already exists, its contents will not be updated even if the metadata in the retrofit has changed. This can cause the cluster deletion to fail. (I think it works with the annotation.)

Would it be possible to set the OwnerReference when creating the Secret? This way, the Secret would be automatically cleaned up regardless of whether the installation succeeds.

As additional context:
I did some tests switching repeatedly between old and new hive versions on the same hub.
When a ClusterDeployment installation failed on the new version, the metadata.json Secret was left behind without cleanup.
After reverting to the old version and creating a successful ClusterDeployment in the same namespace, upgrading hive again caused the existing secret to remain outdated (since forceUpdate=false), resulting in a mismatch between clusterdeprovision data and metadata.json, which led to cluster deletion failure.

That's a great find @huangmingxia!

I'm really not worried about supporting "downgrades". (I think we could also simulate this behavior by creating a dummy Secret of the appropriate name before kicking off the installation with the new build. I'm also not worried about supporting that :) )

However, I agree we should be setting that OwnerReference immediately to avoid the scenario where the Secret is "orphaned" if the installation fails. PR incoming...

Well, mostly. Previously any time installer added a field to metadata.json, we would need to evaluate and possibly add a bespoke field and code path for it to make sure it was supplied to the destroyer at deprovision time. With this change, we're offloading metadata.json verbatim (except in some cases we have to scrub/replace credentials fields -- see HIVE-2804 / openshift#2612) to a new Secret in the ClusterDeployment's namespace, referenced from a new field: ClusterDeployment.Spec.ClusterMetadata.MetadataJSONSecretRef. For legacy clusters -- those created before this change -- we attempt to retrofit the new Secret based on the legacy fields. This is best effort and may not always work. In the future (but not here!) instead of building the installer's ClusterMetadata structure for the destroyer with individual fields from the CD's ClusterMetadata, we'll unmarshal it directly from the contents of this Secret.

An earlier commit ensures that ClusterDeployments have an associated Secret containing the metadata.json emitted by the installer. This change adds a new generic destroyer via the (existing) `hiveutil deprovision` command that consumes this metadata.json to deprovision the cluster. This new behavior is the default, but we also include an escape hatch to run the platform-specific legacy destroyer by setting the following annotation on the ClusterDeployment: `hive.openshift.io/legacy-deprovision: "true"`

A couple of providers (nutanix, vsphere) need bespoke code to populate credentials in the metadata.json object for destroying a cluster. In a prior commit this was being done in the deprovisioner (the new one, that uses metadata.json directly, per HIVE-2302) after ConfigureCreds. Since ConfigureCreds is where we (stay with me) configure creds, and is already platform-specific, it makes more sense to do this work there. This commit refactors to do so. Legacy code paths pass in a `nil` metadata object, which is coded to result in no change from the previous functionality. (In particular, ConfigureCreds is also used when provisioning, where no metadata object is present/necessary.)

openshift-ci · 2025-10-25T02:08:53Z

@2uasimojo: all tests passed!

Full PR test history. Your PR dashboard.

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 Aug 5, 2025

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 Aug 5, 2025

openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 5, 2025

2uasimojo commented Aug 8, 2025

View reviewed changes

pkg/controller/clusterclaim/clusterclaim_controller.go Outdated Show resolved Hide resolved

2uasimojo force-pushed the HIVE-2302/metadata.json-passthrough branch from 8707a79 to d09e43e Compare August 15, 2025 17:59

2uasimojo force-pushed the HIVE-2302/metadata.json-passthrough branch from d09e43e to 13ad458 Compare August 19, 2025 21:20

2uasimojo force-pushed the HIVE-2302/metadata.json-passthrough branch from 13ad458 to ace243e Compare September 9, 2025 20:36

2uasimojo changed the title ~~HIVE-2302: Pass metadata.json through opaquely~~ HIVE-2302, HIVE-2644: Pass metadata.json through opaquely Sep 9, 2025

2uasimojo force-pushed the HIVE-2302/metadata.json-passthrough branch from ace243e to cf8610a Compare September 9, 2025 21:50

2uasimojo force-pushed the HIVE-2302/metadata.json-passthrough branch from cf8610a to 268d7cc Compare September 10, 2025 19:01

2uasimojo force-pushed the HIVE-2302/metadata.json-passthrough branch from 268d7cc to bce1629 Compare September 23, 2025 19:38

2uasimojo force-pushed the HIVE-2302/metadata.json-passthrough branch from bce1629 to cb1b5d5 Compare September 23, 2025 21:31

2uasimojo marked this pull request as ready for review September 23, 2025 21:32

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 Sep 23, 2025

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

openshift-ci bot requested review from dlom and jstuever September 23, 2025 21:32

2uasimojo force-pushed the HIVE-2302/metadata.json-passthrough branch from cb1b5d5 to f6f2464 Compare October 1, 2025 19:16

openshift-ci bot assigned dlom Oct 1, 2025

openshift deleted a comment from openshift-ci bot Oct 1, 2025

2uasimojo force-pushed the HIVE-2302/metadata.json-passthrough branch from f6f2464 to 8158d73 Compare October 1, 2025 20:18

openshift deleted a comment from openshift-ci bot Oct 2, 2025

dlom reviewed Oct 6, 2025

View reviewed changes

contrib/pkg/deprovision/deprovision.go Outdated Show resolved Hide resolved

dlom reviewed Oct 6, 2025

View reviewed changes

pkg/controller/clusterdeployment/clusterdeployment_controller.go Show resolved Hide resolved

2uasimojo force-pushed the HIVE-2302/metadata.json-passthrough branch from 8158d73 to c4a6689 Compare October 16, 2025 20:40

dlom reviewed Oct 20, 2025

View reviewed changes

huangmingxia reviewed Oct 24, 2025

View reviewed changes

2uasimojo added 3 commits October 24, 2025 17:24

2uasimojo force-pushed the HIVE-2302/metadata.json-passthrough branch from c951181 to de21622 Compare October 24, 2025 22:24

HIVE-2302, HIVE-2644: Pass metadata.json through opaquely #2729

Are you sure you want to change the base?

HIVE-2302, HIVE-2644: Pass metadata.json through opaquely #2729

Uh oh!

Conversation

2uasimojo commented Aug 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

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

Uh oh!

Uh oh!

openshift-ci bot commented Aug 5, 2025

Uh oh!

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

Uh oh!

Uh oh!

openshift-ci bot commented Aug 5, 2025

Uh oh!

2uasimojo commented Aug 5, 2025

Uh oh!

Uh oh!

openshift-ci-robot commented Aug 15, 2025 • 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 Aug 15, 2025 • 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 Sep 9, 2025 • 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 Sep 9, 2025 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

2uasimojo commented Sep 9, 2025

Uh oh!

2uasimojo commented Sep 10, 2025

Uh oh!

2uasimojo commented Sep 23, 2025

Uh oh!

2uasimojo commented Sep 23, 2025

Uh oh!

codecov bot commented Sep 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

2uasimojo commented Sep 25, 2025

Uh oh!

2uasimojo commented Oct 1, 2025

Uh oh!

2uasimojo commented Oct 1, 2025

Uh oh!

2uasimojo commented Oct 1, 2025

Uh oh!

2uasimojo commented Oct 1, 2025

Uh oh!

dlom commented Oct 2, 2025

Uh oh!

dlom commented Oct 2, 2025

Uh oh!

openshift-ci bot commented Oct 2, 2025

Uh oh!

2uasimojo commented Oct 2, 2025

Uh oh!

2uasimojo commented Oct 2, 2025

Uh oh!

2uasimojo commented Oct 3, 2025

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

2uasimojo commented Aug 5, 2025 •

edited

Loading

openshift-ci-robot commented Aug 5, 2025 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Aug 5, 2025 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Aug 15, 2025 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Aug 15, 2025 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Sep 9, 2025 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Sep 9, 2025 •

edited by openshift-ci bot

Loading

codecov bot commented Sep 23, 2025 •

edited

Loading