OCPEDGE-2326: add storageclass configuration options to lvms by Neilhamza · Pull Request #1965 · openshift/lvm-operator

Neilhamza · 2026-01-21T11:45:19Z

this PR completes jiras:
https://issues.redhat.com/browse/OCPEDGE-2326
https://issues.redhat.com/browse/OCPEDGE-2327
https://issues.redhat.com/browse/OCPEDGE-2328

Adds configurable StorageClassOptions at the DeviceClass level in LVMCluster, allowing users to control how LVMS-generated StorageClasses are created while respecting Kubernetes immutability guarantees.

Unit tests and e2e coverage will be added in a follow-up PR.

Changes
API

Added StorageClassOptions to DeviceClass with optional:

reclaimPolicy

volumeBindingMode

additionalParameters

additionalLabels

Webhook

Validates StorageClassOptions on create/update

Warns on conflicts with LVMS-owned parameters and labels

Validates label keys/values per Kubernetes rules

Rejects updates to immutable StorageClass fields after creation

Controller

Uses CreateOrUpdate for StorageClass reconciliation

Sets immutable fields at creation time only

Supports day-2 updates for metadata-only fields (additionalLabels)

Ownership-aware label pruning ensures spec is the source of truth

No delete/recreate behavior for StorageClasses

Immutability Model

StorageClass behavior fields are immutable in Kubernetes and are configurable only at creation time.
Metadata-only fields (labels) are safely reconciled day-2 without impacting existing PVCs.

Example
apiVersion: lvm.topolvm.io/v1alpha1
kind: LVMCluster
metadata:
name: lvmcluster
spec:
storage:
deviceClasses:
- name: vg1
storageClassOptions:
reclaimPolicy: Retain
volumeBindingMode: Immediate
additionalParameters:
provisioner-secret-name: my-secret
additionalLabels:
environment: production

openshift-ci-robot · 2026-01-21T11:45:24Z

@Neilhamza: This pull request references OCPEDGE-2326 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:

Introduces configurable StorageClass options at the DeviceClass level, enabling users to customize reclaimPolicy, volumeBindingMode, additionalParameters, and additionalLabels. Supports day-2 operations with full backward compatibility.

JIRA: OCPSTRAT-2718

Changes
API (lvmcluster_types.go)

Added StorageClassOptions struct with optional fields for reclaim policy, volume binding mode, parameters, and labels
All fields use pointer types to distinguish unset (nil) from explicitly set values
Validation (lvmcluster_webhook.go)

Added verifyStorageClassOptions() to warn on LVMS-owned parameter conflicts
Validates label key format per Kubernetes standards
Integrated into create/update webhook paths
Controller (topolvm_storageclass.go)

Implements delete+recreate for immutable fields (reclaimPolicy, volumeBindingMode, parameters)
In-place updates for mutable fields (labels)
Added needsRecreation() and applyAdditionalLabels() helpers
Protects LVMS-managed labels and parameters from override
Immutability Handling
Kubernetes StorageClass spec fields are immutable. This PR follows the canonical pattern:

Detect changes to immutable fields
Delete existing StorageClass
Recreate with new configuration
PVC Safety: Existing PVCs unaffected—they store provisioning info at creation and don't depend on the StorageClass object afterward. Brief <1s window where new PVC creation may fail during recreation.

Example

apiVersion: lvm.topolvm.io/v1alpha1
kind: LVMCluster
metadata:
name: lvmcluster
spec:
storage:
deviceClasses:

name: vg1
storageClassOptions:
reclaimPolicy: Retain
volumeBindingMode: Immediate
additionalParameters:
provisioner-secret-name: my-secret
additionalLabels:
environment: production

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 · 2026-01-21T11:45:50Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Neilhamza
Once this PR has been reviewed and has the lgtm label, please assign jerpeter1 for approval. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

OWNERS

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

openshift-ci-robot · 2026-01-21T11:47:08Z

@Neilhamza: This pull request references OCPEDGE-2326 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:

Introduces configurable StorageClass options at the DeviceClass level, enabling users to customize reclaimPolicy, volumeBindingMode, additionalParameters, and additionalLabels. Supports day-2 operations with full backward compatibility.

Changes
API (lvmcluster_types.go)

Added StorageClassOptions struct with optional fields for reclaim policy, volume binding mode, parameters, and labels
(lvmcluster_webhook.go)

Added verifyStorageClassOptions() to warn on LVMS-owned parameter conflicts
Validates label key format per Kubernetes standards
Integrated into create/update webhook paths
Controller (topolvm_storageclass.go)

Implements delete+recreate for immutable fields (reclaimPolicy, volumeBindingMode, parameters)
In-place updates for mutable fields (labels)
Added needsRecreation() and applyAdditionalLabels() helpers
Protects LVMS-managed labels and parameters from override
Immutability Handling
Kubernetes StorageClass spec fields are immutable. This PR follows the canonical pattern:

Detect changes to immutable fields
Delete existing StorageClass
Recreate with new configuration
PVC Safety: Existing PVCs unaffected—they store provisioning info at creation and don't depend on the StorageClass object afterward. Brief <1s window where new PVC creation may fail during recreation.

Example

apiVersion: lvm.topolvm.io/v1alpha1
kind: LVMCluster
metadata:
name: lvmcluster
spec:
storage:
deviceClasses:

name: vg1
storageClassOptions:
reclaimPolicy: Retain
volumeBindingMode: Immediate
additionalParameters:
provisioner-secret-name: my-secret
additionalLabels:
environment: production

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.

codecov-commenter · 2026-01-21T11:56:09Z

Codecov Report

❌ Patch coverage is 21.26866% with 211 lines in your changes missing coverage. Please review.
✅ Project coverage is 46.83%. Comparing base (0561e12) to head (0e4a655).
⚠️ Report is 57 commits behind head on main.

Files with missing lines	Patch %	Lines
...ollers/lvmcluster/resource/topolvm_storageclass.go	0.00%	82 Missing ⚠️
internal/controllers/lvmcluster/controller.go	19.00%	75 Missing and 6 partials ⚠️
api/v1alpha1/lvmcluster_webhook.go	47.50%	37 Missing and 5 partials ⚠️
internal/controllers/lvmcluster/resource/utils.go	0.00%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1965      +/-   ##
==========================================
- Coverage   48.11%   46.83%   -1.28%     
==========================================
  Files          52       52              
  Lines        3735     3978     +243     
==========================================
+ Hits         1797     1863      +66     
- Misses       1782     1949     +167     
- Partials      156      166      +10

Files with missing lines	Coverage Δ
api/v1alpha1/lvmcluster_types.go	`100.00% <ø> (ø)`
internal/controllers/lvmcluster/resource/utils.go	`0.00% <0.00%> (ø)`
api/v1alpha1/lvmcluster_webhook.go	`71.22% <47.50%> (-7.09%)`	⬇️
internal/controllers/lvmcluster/controller.go	`44.98% <19.00%> (-7.96%)`	⬇️
...ollers/lvmcluster/resource/topolvm_storageclass.go	`0.00% <0.00%> (ø)`

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

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

openshift-ci-robot · 2026-01-21T13:42:34Z

@Neilhamza: This pull request references OCPEDGE-2326 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 completes jiras:
https://issues.redhat.com/browse/OCPEDGE-2326
https://issues.redhat.com/browse/OCPEDGE-2327
https://issues.redhat.com/browse/OCPEDGE-2328

unit testing and e2e will be done in an additional PR

Introduces configurable StorageClass options at the DeviceClass level, enabling users to customize reclaimPolicy, volumeBindingMode, additionalParameters, and additionalLabels. Supports day-2 operations with full backward compatibility.

Changes
API (lvmcluster_types.go)

Added StorageClassOptions struct with optional fields for reclaim policy, volume binding mode, parameters, and labels
(lvmcluster_webhook.go)

Added verifyStorageClassOptions() to warn on LVMS-owned parameter conflicts
Validates label key format per Kubernetes standards
Integrated into create/update webhook paths
Controller (topolvm_storageclass.go)

Implements delete+recreate for immutable fields (reclaimPolicy, volumeBindingMode, parameters)
In-place updates for mutable fields (labels)
Added needsRecreation() and applyAdditionalLabels() helpers
Protects LVMS-managed labels and parameters from override
Immutability Handling
Kubernetes StorageClass spec fields are immutable. This PR follows the canonical pattern:

Detect changes to immutable fields
Delete existing StorageClass
Recreate with new configuration
PVC Safety: Existing PVCs unaffected—they store provisioning info at creation and don't depend on the StorageClass object afterward. Brief <1s window where new PVC creation may fail during recreation.

Example

apiVersion: lvm.topolvm.io/v1alpha1
kind: LVMCluster
metadata:
name: lvmcluster
spec:
storage:
deviceClasses:

name: vg1
storageClassOptions:
reclaimPolicy: Retain
volumeBindingMode: Immediate
additionalParameters:
provisioner-secret-name: my-secret
additionalLabels:
environment: production

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.

qJkee · 2026-01-22T12:35:40Z

/сс

Neilhamza · 2026-01-25T13:31:48Z

test/e2e/helper_test.go

@@ -117,6 +118,57 @@ func DeleteResource(ctx context.Context, obj client.Object) {
 	}, timeout, interval).WithContext(ctx).Should(Satisfy(k8serrors.IsNotFound))
 }



waitForStorageCleanup prevents race where LVM metadata flush is async: vgremove/lvremove
return before disk flush completes, causing next test to find stale metadata (VG exists,
thin-pool missing) and mark cluster Degraded. Observed in HyperShift CI job.

Neilhamza · 2026-01-25T16:44:07Z

/retest

Neilhamza · 2026-01-25T18:25:19Z

/retest list

Neilhamza · 2026-01-25T18:25:44Z

/test e2e-aws-hypershift

Neilhamza · 2026-01-25T20:25:53Z

/test e2e-aws-hypershift

Signed-off-by: nhamza <nhamza@redhat.com>

api/v1alpha1/lvmcluster_types.go

qJkee · 2026-01-28T08:32:15Z

api/v1alpha1/lvmcluster_webhook.go

+		}
+
+		scName := constants.StorageClassPrefix + newDC.Name
+		sc := &storagev1.StorageClass{}


Where do you use it? I can't find anywhere

The sc variable is required for the Get() call right after, which is used to check whether the StorageClass already exists.
This existence check gates the immutability validation:
– If the StorageClass does not exist yet (NotFound), immutability checks are skipped
– If the StorageClass exists, updates to storageClassOptions are rejected

But it can be created during this webhook call. Basically we need to check old and new CR configuration, not with existing objects. The cluster will be reconciled later accordingly

completely rewrote the immutability check in api/v1alpha1/lvmcluster_webhook.go:

removed:

The StorageClass GET call (the r.Get(ctx, types.NamespacedName{Name: scName}, sc)

Any dependency on checking the actual StorageClass object in the cluster

added:

immutableSCFields struct (lines 623-629) - holds only the immutable fields we care about

effectiveImmutable() helper (lines 631-661) - extracts immutable fields from a DeviceClass and applies defaults (so nil -> WaitForFirstConsumer, nil -> Delete, etc.)

verifyImmutableStorageClassFields() rewrite (lines 663-693) - now compares old CR spec vs new CR spec only, not cluster objects:

api/v1alpha1/lvmcluster_webhook.go

internal/controllers/lvmcluster/resource/topolvm_storageclass.go

qJkee · 2026-01-28T09:08:56Z

internal/controllers/lvmcluster/resource/topolvm_storageclass.go

 	return sc
 }
+
+func (s topolvmStorageClass) applyAdditionalLabels(


Why do we need this? Why do we need to store additional labels in annotation?

he annotation tracks which labels were added by LVMS via additionalLabels so they
can be safely pruned when removed from the spec, without touching user's own labels.

Example scenario:

User adds label "env=prod" via additionalLabels then annotation stores "env"

User removes "env=prod" from spec then we check annotation, see "env" was LVMS-managed

We safely delete "env" label from StorageClass

Any labels NOT in the annotation (user's own labels) are left untouched

This prevents orphaned labels when users modify their additionalLabels configuration.
See applyAdditionalLabels() lines 258-263 for pruning logic.

if annotation LVMS managed - user is unable to modify it. It's our object, we manage it, and we allow user to modify only certain fields

Right now (current implemntation) LVMS uses a partial ownership model for StorageClass labels: we only manage the keys coming from additionalLabels, and the annotation tracks which keys LVMS previously applied so we can safely prune them when removed from the spec without touching unrelated labels added by admins or external tooling.

The alternative (to implement your suggestion) would be strict ownership, where LVMS overwrites the entire labels map from the CR on every reconcile (no annotation tracking needed), but that would drop any non-LVMS labels set directly on the StorageClass.
The first approach keeps day-2 reconciliation safe while avoiding unintended deletion of user/policy-applied labels.

can i have your suggestion on how to proceed?

Signed-off-by: nhamza <nhamza@redhat.com>

Neilhamza · 2026-01-29T12:46:06Z

/retest

Signed-off-by: nhamza <nhamza@redhat.com>

Neilhamza · 2026-01-29T15:33:35Z

/retest Red Hat Konflux / lvm-operator-integration-tests-4-21 / lvm-operator-4-21

Neilhamza · 2026-01-29T15:34:53Z

/test Red Hat Konflux / lvm-operator-integration-tests-4-21 / lvm-operator-4-21

Signed-off-by: nhamza <nhamza@redhat.com>

Neilhamza · 2026-01-29T19:08:29Z

/retest

Neilhamza · 2026-01-29T20:45:54Z

/retest

Signed-off-by: nhamza <nhamza@redhat.com>

qJkee · 2026-01-28T16:18:49Z

api/v1alpha1/lvmcluster_webhook.go

+	}
+
+	for _, deviceClass := range l.Spec.Storage.DeviceClasses {
+		if deviceClass.StorageClassOptions == nil {


what if they were exist and now deleted? Will values be defaulted and operator might try to change immutable parameters and fail?

Added effectiveImmutable() helper that applies defaults to both old and new specs before comparison, catching nil -> defaults immutability violations.

qJkee · 2026-01-28T16:21:13Z

api/v1alpha1/lvmcluster_webhook.go

+		}
+
+		scName := constants.StorageClassPrefix + newDC.Name
+		sc := &storagev1.StorageClass{}


But it can be created during this webhook call. Basically we need to check old and new CR configuration, not with existing objects. The cluster will be reconciled later accordingly

internal/controllers/lvmcluster/resource/topolvm_storageclass.go

qJkee · 2026-02-04T06:45:02Z

internal/controllers/lvmcluster/controller.go

+					continue
+				}
+			}
+


you need to check if deletion timestamp is not nil, otherwise delete will return error

Added if !pv.DeletionTimestamp.IsZero() { continue } check before attempting delete in cleanup function.

internal/controllers/lvmcluster/resource/topolvm_storageclass.go

qJkee · 2026-02-04T07:29:48Z

internal/controllers/lvmcluster/controller.go

+	}
+
+	// Delete LogicalVolumes
+	lvList := &topolvmv1.LogicalVolumeList{}


topolvm logical volumes managed by topolvm controllers and will be deleted automatically when lvmcluster is being deleted

this is the most tricky part, this function is only called when we are in retain policy. if we dont manually delete LogicalVolumes the user cannot delete lvm cluster because it will simply hang - since there will be LV's leftover (which is retain..)

i can either go with the option to leave the code as is, or block the user from deleting lvm-cluster and send a message that he must manually delete retained volumes (and finalizes)

i updated code by adding multiple gates that checks if we are in/touching retain related
Kept LV deletion scoped only to Retain deviceClasses with bounded wait. Without this, LV finalizers block deletion after TopoLVM controller is removed.

internal/controllers/lvmcluster/resource/topolvm_storageclass.go

qJkee · 2026-02-04T14:12:14Z

internal/controllers/lvmcluster/resource/topolvm_storageclass.go

+
+			// Only set immutable spec fields on creation (ResourceVersion is empty for new objects)
+			if sc.ResourceVersion == "" {
+				sc.Provisioner = desired.Provisioner


btw, do we need this? We do query actual StorageClass in s.getTopolvmStorageClasses. Can't we check for immutable fields there so we won't override them using actual StorageClass? This would also reduce this function size and avoid duplication in construction of StorageClass

We still need this guard because getTopolvmStorageClasses() builds the desired spec, but CreateOrUpdate will re-run the mutate function on every reconcile, without the ResourceVersion == "" check we could accidentally try to update immutable SC fields. This makes sure immutable fields are only set on create, so we don’t accidentally try to change them on later reconciles

qJkee · 2026-02-04T14:26:14Z

internal/controllers/lvmcluster/resource/topolvm_storageclass.go

 	return sc
 }
+
+func (s topolvmStorageClass) applyAdditionalLabels(


if annotation LVMS managed - user is unable to modify it. It's our object, we manage it, and we allow user to modify only certain fields

Signed-off-by: nhamza <nhamza@redhat.com>

Neilhamza · 2026-02-05T11:42:34Z

/retest

openshift-ci · 2026-02-05T11:51:24Z

@Neilhamza: 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/snyk-deps	`0e4a655`	link	false	`/test snyk-deps`

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 21, 2026

Neilhamza changed the title ~~OCPEDGE-2326: add storageclass configuration options to lvms~~ WIP: OCPEDGE-2326: add storageclass configuration options to lvms Jan 21, 2026

openshift-ci bot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Jan 21, 2026

openshift-ci bot requested review from eggfoobar and jerpeter1 January 21, 2026 11:45

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 21, 2026

Neilhamza force-pushed the storageclassoptions branch 2 times, most recently from 8a06966 to bd2bf5a Compare January 21, 2026 12:19

Neilhamza force-pushed the storageclassoptions branch from fc7f998 to d8a2f74 Compare January 21, 2026 14:15

Neilhamza changed the title ~~WIP: OCPEDGE-2326: add storageclass configuration options to lvms~~ OCPEDGE-2326: add storageclass configuration options to lvms Jan 22, 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 22, 2026

Neilhamza changed the title ~~OCPEDGE-2326: add storageclass configuration options to lvms~~ WIP: OCPEDGE-2326: add storageclass configuration options to lvms Jan 22, 2026

Neilhamza commented Jan 25, 2026

View reviewed changes

Neilhamza changed the title ~~WIP: OCPEDGE-2326: add storageclass configuration options to lvms~~ OCPEDGE-2326: add storageclass configuration options to lvms Jan 25, 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 25, 2026

Neilhamza added 7 commits January 26, 2026 13:50

update logic for recreation of lvms

d3469fe

Signed-off-by: nhamza <nhamza@redhat.com>

add debugging for the hypershift failures

7d48f4f

Signed-off-by: nhamza <nhamza@redhat.com>

update test logic

63ccecd

Signed-off-by: nhamza <nhamza@redhat.com>

apply fixes

44f0d52

Signed-off-by: nhamza <nhamza@redhat.com>

update test

ca70857

Signed-off-by: nhamza <nhamza@redhat.com>

trimming

0ea3f76

Signed-off-by: nhamza <nhamza@redhat.com>

readd comments

56c96a7

Signed-off-by: nhamza <nhamza@redhat.com>

Neilhamza force-pushed the storageclassoptions branch from d1dd8d6 to b8ef8f6 Compare January 26, 2026 11:51

openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jan 26, 2026

remove deletion logic, keep using createorupdate

7c139c0

Signed-off-by: nhamza <nhamza@redhat.com>

Neilhamza force-pushed the storageclassoptions branch from b8ef8f6 to 7c139c0 Compare January 26, 2026 12:11

Neilhamza changed the title ~~[WIP] OCPEDGE-2326: add storageclass configuration options to lvms~~ OCPEDGE-2326: add storageclass configuration options to lvms Jan 26, 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 26, 2026

qJkee requested changes Jan 28, 2026

View reviewed changes

Neilhamza added 2 commits January 28, 2026 12:40

update per code review

5e51860

Signed-off-by: nhamza <nhamza@redhat.com>

allow additionallabels in day-2

2076bd7

Signed-off-by: nhamza <nhamza@redhat.com>

update labeling to avoid reconcile churn

757be39

Signed-off-by: nhamza <nhamza@redhat.com>

update to stop reconcile while deletion

869e624

Signed-off-by: nhamza <nhamza@redhat.com>

fix deleting lvm cluster hangs

ce7d644

Signed-off-by: nhamza <nhamza@redhat.com>

Neilhamza requested a review from qJkee February 3, 2026 08:20

qJkee reviewed Feb 4, 2026

View reviewed changes

update per code review

0e4a655

Signed-off-by: nhamza <nhamza@redhat.com>

Neilhamza requested a review from qJkee February 5, 2026 09:48

		@@ -117,6 +118,57 @@ func DeleteResource(ctx context.Context, obj client.Object) {
		}, timeout, interval).WithContext(ctx).Should(Satisfy(k8serrors.IsNotFound))
		}

Conversation

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

Uh oh!

Uh oh!

openshift-ci-robot commented Jan 21, 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 bot commented Jan 21, 2026

Uh oh!

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

Uh oh!

Uh oh!

codecov-commenter commented Jan 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

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

Uh oh!

Uh oh!

qJkee commented Jan 22, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Neilhamza commented Jan 25, 2026

Uh oh!

Neilhamza commented Jan 25, 2026

Uh oh!

Neilhamza commented Jan 25, 2026

Uh oh!

Neilhamza commented Jan 25, 2026

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!

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!

Neilhamza commented Jan 29, 2026

Uh oh!

Neilhamza commented Jan 29, 2026

Uh oh!

Neilhamza commented Jan 29, 2026

Uh oh!

Neilhamza commented Jan 29, 2026

Uh oh!

Neilhamza commented Jan 29, 2026

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!

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!

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

Neilhamza commented Jan 21, 2026 •

edited

Loading

openshift-ci-robot commented Jan 21, 2026 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Jan 21, 2026 •

edited by openshift-ci bot

Loading

codecov-commenter commented Jan 21, 2026 •

edited

Loading

openshift-ci-robot commented Jan 21, 2026 •

edited by openshift-ci bot

Loading

Neilhamza Feb 4, 2026 •

edited

Loading