OCPBUGS-40906: Add encapsulation flag to IPsecConfig struct #1472

mccv1r0 · 2023-05-25T15:51:48Z

Add encapsulation flag to IPsecConfig struct.

This flag allows UDP encapsulation of IPsec related packets for things like firewall and NAT traversal

See RFC 3948 for specific uses

openshift-ci · 2023-05-25T15:52:14Z

Hello @mccv1r0! 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-bot · 2023-08-24T01:01:10Z

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

openshift-bot · 2023-10-01T00:30:33Z

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

openshift-bot · 2023-10-31T08:00:33Z

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

openshift-ci · 2023-10-31T08:00:54Z

@openshift-bot: Closed this PR.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

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/test-infra repository.

yocum137 · 2024-10-10T17:59:45Z

Please re-open this PR for IPSec encapsulation on IBM VPC cloud.

pperiyasamy · 2024-11-06T10:47:14Z

/reopen

openshift-ci · 2024-11-06T10:47:37Z

@pperiyasamy: Reopened this PR.

In response to this:

/reopen

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.

pperiyasamy · 2024-11-06T17:15:30Z

/retitle OCPBUGS-40906: Add encapsulation flag to IPsecConfig struct

openshift-ci-robot · 2024-11-06T17:15:39Z

@mccv1r0: This pull request references Jira Issue OCPBUGS-40906, which is invalid:

expected the bug to target the "4.18.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.

In response to this:

Add encapsulation flag to IPsecConfig struct.

This flag allows UDP encapsulation of IPsec related packets for things like firewall and NAT traversal

See RFC 3948 for specific uses

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.

pperiyasamy · 2024-11-06T17:17:13Z

/jira refresh

openshift-ci-robot · 2024-11-06T17:17:20Z

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

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

New user facing features should have an enhancement and a feature gate for their introduction. Do you have any design docs for this yet, or thoughts on feature gating this and what you'll need to do to be able to declare this stable?

JoelSpeed · 2024-11-09T17:57:57Z

operator/v1/types_network.go

+	// This will be effective only when mode is configured with `Full`,
+	// otherwise it will be ignored.


You can add CEL to the parent struct to prevent this being set when the mode is not full.
Base this field on the OptionalMember example please

Suggested change

// This will be effective only when mode is configured with `Full`,

// otherwise it will be ignored.

// This is permitted only when mode is configured with `Full`,

// and forbidden otherwise.

@JoelSpeed thanks for the reference. added CEL to validate full parameter, is that fine ?

JoelSpeed · 2024-11-09T18:00:18Z

operator/v1/types_network.go

+type IPsecFullModeConfig struct {
+	// encapsulation option to enabled or disable rfc3949 encapsulation of IKE and IPsec
+	// encryption packets
+	// +kubebuilder:validation:Enum:=yes;no;""


Yes and No are as bad as true and false. What does this actually do for an end user? What kind of encapsulation is this? Think about this from an end user perspective.

What difference does it make to me, as an end user, if I do, or do not have this field set to yes or no?

This option is going to set into OVN/OVS something like this: https://docs.openvswitch.org/en/latest/tutorials/ipsec/#custom-options and finally going to be set as ipsec config option for an ipsec tunnel.

encapsulation In some cases, for example when ESP packets are filtered or when a broken IPsec peer does not properly recognise NAT, it can be useful to force RFC-3948 encapsulation. In other cases, where IKE is NAT'ed but ESP packets can or should flow without encapsulation, it can be useful to ignore the NAT-Traversal auto-detection. encapsulation=yes forces the NAT detection code to lie and tell the remote peer that RFC-3948 encapsulation (ESP in port 4500 packets) is required. encapsulation=no ignores the NAT detection causing ESP packets to send send without encapsulation. The default value of encapsulation=auto follows the regular outcome of the NAT auto-detection code performed in IKE. This option replaced the obsoleted forceencaps option.

https://libreswan.org/man/ipsec.conf.5.html

So I don't see any other values to represent this. Please suggest.

@JoelSpeed here is how implementation looks like for this new API: openshift/cluster-network-operator#2573.

Seems to me like there are three modes if I read this correctly? Force, Auto, Disable? With the default being Auto?

Could you briefly explain to me, what actually is encapsulation in this context? Does AH or ESP, transport or tunnel come into this in any way? https://support.huawei.com/enterprise/en/doc/EDOC1100301600/c5d5a9b/understanding-ipsec-encapsulation-modes

I'm still trying to understand how we explain this to an end user in terms that they can easily understand

if ESP (IP Protocol 50) is not supported this uses UDP encapsulation. This is required for IBMCloud for example.

If your network or firewall blocks less common IP protocols like IP Protocol 50, this setting allows the use of standard UDP packets on ports 500 and 4500 instead.

IBMCloud IPI already uses UDP encap, it's just hardcoded. This supports platform: none or other edge cases.

We should probably add UDP port 4500 somewhere in descriptions.

Other UPI Docs already indicate UDP port 4500 is required, so we should be covered.
e.g. AWS UPI:

Name Description Protocol Port

MasterIngressIpsecNat IPsec NAT-T packets udp 4500

MasterIngressWorkerIpsecNat IPsec NAT-T packets udp 4500

Thanks @rbbratta about firewall use case, The NAT-T is very much needed there.

@JoelSpeed The IPsec tunnel is configured between OCP nodes in tunnel mode on the Geneve overlay traffic which carries pod payload traffic. Once IPsec SAs are established between nodes, then Gevenve traffic is encrypted with ESP header. So NAT-T (UDP) encapsulation happens on ESP payload so that it can pass firewalls and also compatible with intermediate NAT devices.

updated with 3 encapsulation modes (yes, no and auto) now.

Can we please avoid the use of yes and no as enum values, they are as bad as true and false. Enum values should be descriptive where possible, I still think Force and Disable are better

Think of it this way:

Yes encapsulation

No encapsulation
vs

Force encapsulation

Disable encapsulation

The latter two flow better in a sentence at a minimum

Also, enum values should be PascalCase

yes @JoelSpeed , done.

JoelSpeed · 2024-11-09T18:00:35Z

operator/v1/types_network.go

+	// This will be effective only when mode is configured with `Full`,
+	// otherwise it will be ignored.
+	// +optional
+	Full IPsecFullModeConfig `json:"full,omitempty"`


This needs to be a pointer, you can't have an omitempty with a non-pointer struct

pperiyasamy · 2024-11-11T13:58:45Z

New user facing features should have an enhancement and a feature gate for their introduction. Do you have any design docs for this yet, or thoughts on feature gating this and what you'll need to do to be able to declare this stable?

This is a minor change w.r.t implementation and addressing this for a bug OCPBUGS-40906, do you still recommend to have feature gate and design doc update for this ?

pperiyasamy · 2024-11-21T11:39:29Z

/remove-lifecycle rotten

JoelSpeed · 2024-11-22T12:39:23Z

operator/v1/types_network.go

+	// This is permitted only when mode is configured with `Full`,
+	// and forbidden otherwise.
+	// +unionMember,optional
+	Full *IPsecFullModeConfig `json:"full,omitempty"`


Needs an explicit optional tag too please

Suggested change

Full *IPsecFullModeConfig `json:"full,omitempty"`

// +optional

Full *IPsecFullModeConfig `json:"full,omitempty"`

JoelSpeed · 2024-11-22T12:47:22Z

operator/v1/types_network.go

+type IPsecFullModeConfig struct {
+	// encapsulation option to enabled or disable rfc3949 encapsulation of IKE and IPsec
+	// encryption packets
+	// +kubebuilder:validation:Enum:=yes;no;""


Seems to me like there are three modes if I read this correctly? Force, Auto, Disable? With the default being Auto?

Could you briefly explain to me, what actually is encapsulation in this context? Does AH or ESP, transport or tunnel come into this in any way? https://support.huawei.com/enterprise/en/doc/EDOC1100301600/c5d5a9b/understanding-ipsec-encapsulation-modes

I'm still trying to understand how we explain this to an end user in terms that they can easily understand

pperiyasamy · 2024-11-27T16:45:10Z

/retest-required

pperiyasamy · 2024-11-27T16:45:35Z

/retest

openshift-ci · 2024-11-27T18:54:26Z

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

Test name	Commit	Details	Required	Rerun command
ci/prow/okd-scos-e2e-aws-ovn	`93e98d6`	link	false	`/test okd-scos-e2e-aws-ovn`

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.

everettraven · 2024-12-13T13:46:10Z

operator/v1/types_network.go

+	// encapsulation option to configure libreswan on how inter-pod traffic across nodes
+	// are encapsulated to handle NAT traversal. When configured it uses UDP port 4500
+	// for the encapsulation.


I think the purpose of this field is documented well in this GoDoc, but I would like to see more information outlined on:

Limitations of this field. I would recommend explicitly calling out the allowed values in the GoDoc and describing how each setting influences the behavior

As of writing, this field is optional and doesn't look to have a default - what does not setting this field mean for encapsulation?

As Bryce says, we need to add godoc explaining the options, this typically takes the form of

// Valid values are Force, Disable, Auto and omitted. // Force means ... // Disable means ... // Auto means ... // When omitted, this means no opinion and the platform is left to choose a reasonable default, which is subject to change over time. // The current default is ...

Also, given this is optional/omitempty you don't need "" as a valid value in the enum

sure, updated godoc with above info, hope it's fine now.

everettraven · 2024-12-13T13:49:34Z

operator/v1/types_network.go

+	// for the encapsulation.
+	// +kubebuilder:validation:Enum:=Force;Disable;Auto;""
+	// +optional
+	Encap Encapsulation `json:"encapsulation,omitempty"`


Any particular reason why the struct field name is Encap and not Encapsulation? Generally, I would recommend having the Go struct field name match the JSON field name where possible.

ok, changed it.

everettraven · 2024-12-13T13:52:20Z

operator/v1/types_network.go

+	// DisableEncapsulation disables UDP encapsulation even if NAT is present.
+	DisableEncapsulation = "Disable"


What does "disable" mean here? Is it semantically equivalent to "no encapsulation"? Would using something like None instead of Disable be a bit more intuitive for the semantic meaning of "no encapsulation"?

I know that generally we try to avoid the terms "enable" and "disable" because they are often overloaded.

In this case I think we were aiming for the antonym of Force.

There are three states for the encapsulation. Either you make sure it's on (force), you make sure it's off (disable), or you let the connection negotiate based on the other end (auto).

Given that context, I leant towards disable over none, wdyt?

Maybe something like Always, Never, Auto would help avoid "Disabled" and be more naturally descriptive?

Thinking from a UX perspective, I think Always and Never would be easier to remember as "always encapsulate" and "never encapsulate" than something like Force and Disabled.

Provided the additional context, I don't think Force and Disabled are bad options

I like the suggestion of Always and Never, what do you think @pperiyasamy ?

+1
updated it with Always and Never options now.

JoelSpeed · 2024-12-13T11:42:32Z

operator/v1/types_network.go

+	// for the encapsulation.
+	// +kubebuilder:validation:Enum:=Force;Disable;Auto;""
+	// +optional
+	Encap Encapsulation `json:"encapsulation,omitempty"`


Should this be required when Full is provided? Do you expect new parameters to be added here in the future?

Trying to work out if we can make it a validation error to set

ipsecConfig: mode: Full full: {}

Since this would be semantically equivalent to

ipsecConfig: mode: Full

We could use +kubebuilder:validation:MinProperties:=1 to make sure that at least one property is added, if you don't think we should make this field required when full: {}, WDYT?

at present full option may not be configured at all for most of the clusters, so let it be compatible with OCP upgrades as well.
when customer wants to configure NAT-T encapsulation option other than default value, then they are free to configure it via full struct parameter.
of course there can be future requirements to customize ipsec connection on Full mode.

I think what Joel is getting at here is that making it so there is only one way to represent the "no configuration" option is a better UX choice as mentioned in the OpenShift API conventions doc here: https://github.com/openshift/enhancements/blob/master/dev-guide/api-conventions.md#only-one-phrasing-for-each-idea

It seems like there is currently two ways to set the "I have no opinion as to the configuration when mode is set to Full" idea by doing

ipsecConfig: mode: Full

and

ipsecConfig: mode: Full full: {}

In order to achieve this single representation, I think Joel is suggesting to either:

Make the ipsecConfig.full.encapsulation field required

Make it such that when ipsecConfig.full is specified, at least one field member of the struct must also be specified

Either of these would make it so the only valid way to set the "no configuration" option is to not include the ipsecConfig.full field in your YAML that you apply to the cluster even when ipsecConfig.mode is set to Full.

yes @everettraven , I can understand it now and the suggestion makes sense.
adding +kubebuilder:validation:MinProperties:=1 on the struct to support:

Make it such that when ipsecConfig.full is specified, at least one field member of the struct must also be specified

JoelSpeed · 2024-12-13T14:02:20Z

operator/v1/types_network.go

+	// DisableEncapsulation disables UDP encapsulation even if NAT is present.
+	DisableEncapsulation = "Disable"


In this case I think we were aiming for the antonym of Force.

There are three states for the encapsulation. Either you make sure it's on (force), you make sure it's off (disable), or you let the connection negotiate based on the other end (auto).

Given that context, I leant towards disable over none, wdyt?

JoelSpeed · 2024-12-13T14:03:13Z

operator/v1/types_network.go

+	// encapsulation option to configure libreswan on how inter-pod traffic across nodes
+	// are encapsulated to handle NAT traversal. When configured it uses UDP port 4500
+	// for the encapsulation.


As Bryce says, we need to add godoc explaining the options, this typically takes the form of

// Valid values are Force, Disable, Auto and omitted. // Force means ... // Disable means ... // Auto means ... // When omitted, this means no opinion and the platform is left to choose a reasonable default, which is subject to change over time. // The current default is ...

Also, given this is optional/omitempty you don't need "" as a valid value in the enum

pperiyasamy · 2024-12-16T09:30:57Z

/assign @huiran0826

Signed-off-by: Michael Cambria <[email protected]> Signed-off-by: Periyasamy Palanisamy <[email protected]>

JoelSpeed · 2024-12-18T13:58:24Z

/test all
/lgtm

openshift-ci · 2024-12-18T13:59:45Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: JoelSpeed, mccv1r0

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~~ [JoelSpeed]

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 · 2024-12-18T15:07:30Z

@mccv1r0: Jira Issue OCPBUGS-40906: Some pull requests linked via external trackers have merged:

openshift/api#1472

The following pull requests linked via external trackers have not merged:

openshift/cluster-network-operator#2573 is open

These pull request must merge or be unlinked from the Jira bug in order for it to move to the next state. Once unlinked, request a bug refresh with /jira refresh.

Jira Issue OCPBUGS-40906 has not been moved to the MODIFIED state.

In response to this:

Add encapsulation flag to IPsecConfig struct.

This flag allows UDP encapsulation of IPsec related packets for things like firewall and NAT traversal

See RFC 3948 for specific uses

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.

pperiyasamy · 2024-12-18T15:25:51Z

Thanks @JoelSpeed and @everettraven for the reviews and merging it finally !
It was a good exercise for me from API perspective.

openshift-ci bot added the size/S Denotes a PR that changes 10-29 lines, ignoring generated files. label May 25, 2023

openshift-ci bot requested review from adambkaplan and eparis May 25, 2023 15:55

mccv1r0 mentioned this pull request Jun 8, 2023

SDN-3223:Use encapsulation=true for IBM Cloud openshift/cluster-network-operator#1800

Merged

openshift-ci bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Aug 24, 2023

openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Aug 31, 2023

openshift-ci bot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Oct 1, 2023

openshift-ci bot closed this Oct 31, 2023

openshift-ci bot reopened this Nov 6, 2024

pperiyasamy force-pushed the api-encaps branch from 4aba5ae to 870a601 Compare November 6, 2024 13:44

openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Nov 6, 2024

openshift-ci bot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Nov 6, 2024

openshift-ci bot changed the title ~~Add encapsulation flag to IPsecConfig struct~~ OCPBUGS-40906: Add encapsulation flag to IPsecConfig struct Nov 6, 2024

openshift-ci-robot added jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. labels Nov 6, 2024

openshift-ci-robot added the jira/valid-bug Indicates that a referenced Jira bug is valid for the branch this PR is targeting. label Nov 6, 2024

pperiyasamy force-pushed the api-encaps branch from 870a601 to 50c1c3c Compare November 8, 2024 18:02

openshift-ci bot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Nov 8, 2024

JoelSpeed reviewed Nov 9, 2024

View reviewed changes

pperiyasamy force-pushed the api-encaps branch from 50c1c3c to f9aadd6 Compare November 11, 2024 11:32

openshift-ci bot removed the lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. label Nov 21, 2024

pperiyasamy force-pushed the api-encaps branch from f9aadd6 to 764cdc8 Compare November 21, 2024 12:32

pperiyasamy mentioned this pull request Nov 21, 2024

OCPBUGS-40906: Implement IPsec NAT-Traversal encapsulation option openshift/cluster-network-operator#2573

Open

JoelSpeed reviewed Nov 22, 2024

View reviewed changes

pperiyasamy force-pushed the api-encaps branch from 764cdc8 to 93e98d6 Compare November 26, 2024 12:32

pperiyasamy force-pushed the api-encaps branch from 93e98d6 to 30b31e7 Compare December 4, 2024 11:48

everettraven reviewed Dec 13, 2024

View reviewed changes

JoelSpeed reviewed Dec 13, 2024

View reviewed changes

pperiyasamy force-pushed the api-encaps branch from 30b31e7 to 6362983 Compare December 16, 2024 09:19

openshift-ci bot assigned huiran0826 Dec 16, 2024

Add encapsulation flag to IPsecConfig struct

e25809c

Signed-off-by: Michael Cambria <[email protected]> Signed-off-by: Periyasamy Palanisamy <[email protected]>

pperiyasamy force-pushed the api-encaps branch from 6362983 to e25809c Compare December 16, 2024 17:52

openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Dec 18, 2024

openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Dec 18, 2024

openshift-merge-bot bot merged commit a3fb7a2 into openshift:master Dec 18, 2024
11 checks passed

		// This will be effective only when mode is configured with `Full`,
		// otherwise it will be ignored.

Name	Description	Protocol	Port
MasterIngressIpsecNat	IPsec NAT-T packets	udp	4500
MasterIngressWorkerIpsecNat	IPsec NAT-T packets	udp	4500

	Full *IPsecFullModeConfig `json:"full,omitempty"`
	// +optional
	Full *IPsecFullModeConfig `json:"full,omitempty"`

		// DisableEncapsulation disables UDP encapsulation even if NAT is present.
		DisableEncapsulation = "Disable"

OCPBUGS-40906: Add encapsulation flag to IPsecConfig struct #1472

OCPBUGS-40906: Add encapsulation flag to IPsecConfig struct #1472

Conversation

mccv1r0 commented May 25, 2023

openshift-ci bot commented May 25, 2023

openshift-bot commented Aug 24, 2023

openshift-bot commented Oct 1, 2023

openshift-bot commented Oct 31, 2023

openshift-ci bot commented Oct 31, 2023

yocum137 commented Oct 10, 2024

pperiyasamy commented Nov 6, 2024

openshift-ci bot commented Nov 6, 2024

pperiyasamy commented Nov 6, 2024

openshift-ci-robot commented Nov 6, 2024

pperiyasamy commented Nov 6, 2024

openshift-ci-robot commented Nov 6, 2024

JoelSpeed left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pperiyasamy commented Nov 11, 2024

pperiyasamy commented Nov 21, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pperiyasamy commented Nov 27, 2024

pperiyasamy commented Nov 27, 2024

openshift-ci bot commented Nov 27, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pperiyasamy commented Dec 16, 2024

JoelSpeed commented Dec 18, 2024

openshift-ci bot commented Dec 18, 2024

openshift-ci-robot commented Dec 18, 2024

pperiyasamy commented Dec 18, 2024