OSDOCS-8651: Edits from content audit #73505

ahardin-rh · 2024-03-20T20:53:28Z

Version(s):
4.15+

Issue:
https://issues.redhat.com/browse/OSDOCS-8651

Link to docs preview:
https://73505--ocpdocs-pr.netlify.app/openshift-enterprise/latest/networking/dns-operator

QE review:

QE has approved this change.

openshift-ci-robot · 2024-03-20T20:53:33Z

@ahardin-rh: This pull request references OSDOCS-8651 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.16.0" version, but no target version was set.

In response to this:

Version(s):
4.15+

Issue:
(https://issues.redhat.com/browse/OSDOCS-8651

Link to docs preview:

QE review:

QE has approved this change.

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.

ocpdocs-previewbot · 2024-03-20T21:01:16Z

🤖 Wed Mar 27 15:01:01 - Prow CI generated the docs preview:
https://73505--ocpdocs-pr.netlify.app

modules/nw-controlling-dns-pod-placement.adoc

modules/nw-dns-operatorloglevel.adoc

openshift-ci-robot · 2024-03-22T14:40:37Z

@ahardin-rh: This pull request references OSDOCS-8651 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.16.0" version, but no target version was set.

In response to this:

Version(s):
4.15+

Issue:
(https://issues.redhat.com/browse/OSDOCS-8651

Link to docs preview:
https://73505--ocpdocs-pr.netlify.app/openshift-enterprise/latest/networking/dns-operator

QE review:

QE has approved this change.

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.

ahardin-rh · 2024-03-22T14:45:16Z

@candita Thank you again for your awesome feedback. I implemented the updates as you noted. Can you please scan these changes to see if I missed anything?

@melvinjoseph86 Can you please provide QE ack? These edits are for clarity and an improved customer experience. Thank you!

candita · 2024-03-22T15:13:00Z

/assign

openshift-ci-robot · 2024-03-22T17:54:47Z

@ahardin-rh: This pull request references OSDOCS-8651 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.16.0" version, but no target version was set.

In response to this:

Version(s):
4.15+

Issue:
https://issues.redhat.com/browse/OSDOCS-8651

Link to docs preview:
https://73505--ocpdocs-pr.netlify.app/openshift-enterprise/latest/networking/dns-operator

QE review:

QE has approved this change.

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.

kcarmichael08

Some minor style and wording suggestions. This looks really good!

kcarmichael08 · 2024-03-22T20:49:09Z

modules/nw-controlling-dns-pod-placement.adoc


-As a cluster administrator, you can use a custom node selector to configure the daemon set for CoreDNS to run or not run on certain nodes.
+Though not a common operation, you might find a need to control which nodes have CoreDNS pods assigned and running. For example, if the cluster administrator has configured security policies that can prohibit communication between pairs of nodes, that would necessitate restricting the set of nodes on which the daemonset for CoreDNS runs. If DNS pods are running on some nodes in the cluster and the nodes where DNS pods are not running have network connectivity to nodes where DNS pods are running, DNS service will be available to all pods.


Suggested change

Though not a common operation, you might find a need to control which nodes have CoreDNS pods assigned and running. For example, if the cluster administrator has configured security policies that can prohibit communication between pairs of nodes, that would necessitate restricting the set of nodes on which the daemonset for CoreDNS runs. If DNS pods are running on some nodes in the cluster and the nodes where DNS pods are not running have network connectivity to nodes where DNS pods are running, DNS service will be available to all pods.

You might find a need to control which nodes have CoreDNS pods assigned and running, although this is not a common operation. For example, if the cluster administrator has configured security policies that can prohibit communication between pairs of nodes, that would necessitate restricting the set of nodes on which the daemonset for CoreDNS runs. If DNS pods are running on some nodes in the cluster and the nodes where DNS pods are not running have network connectivity to nodes where DNS pods are running, DNS service will be available to all pods.

suggest changing a bit, your call

kcarmichael08 · 2024-03-22T21:02:45Z

modules/nw-dns-cache-tuning.adoc

+oc get configmap/dns-default -n openshift-dns -o yaml
+----
+
+You should see entries that look like this for the changes made above:


Since you used . for the first step, this should also be a numbered step (for example, "Verify that you see entries that look like the following example:"). Otherwise, use an asterisk for the first step.

IBM Style recommends not using "above, below, etc." to refer to locations in the doc.

kcarmichael08 · 2024-03-22T21:03:45Z

modules/nw-dns-forward.adoc

@@ -8,7 +8,7 @@

 You can use DNS forwarding to override the default forwarding configuration in the `/etc/resolv.conf` file in the following ways:

-* Specify name servers for every zone. If the forwarded zone is the Ingress domain managed by {product-title}, then the upstream name server must be authorized for the domain.
+* Specify name servers (`spec.servers`) for every zone. If the forwarded zone is the Ingress domain managed by {product-title}, then the upstream name server must be authorized for the domain.


does "ingress" need capitalization?

kcarmichael08 · 2024-03-22T21:06:21Z

modules/nw-dns-forward.adoc

+<6> Determines the order in which upstream servers listed in `upstreams` are selected for querying. You can specify one of these values: `Random`, `RoundRobin`, or `Sequential`. The default value is `Sequential`.
+<7> When omitted, the platform chooses a default, normally the protocol of the original client request. Set to `TCP` to specify that the platform should use TCP for all upstream DNS requests, even if the client request uses UDP.
+<8> Used to configure the transport type, server name, and optional custom CA or CA bundle to use when forwarding DNS requests to an upstream resolver.
+<9> You can specify two types of `upstreams` - `SystemResolvConf` or `Network`. `SystemResolvConf` configures the upstream to use `/etc/resolv.conf` and `Network` defines a `Networkresolver`. You can specify one or both.


Suggested change

<9> You can specify two types of `upstreams` - `SystemResolvConf` or `Network`. `SystemResolvConf` configures the upstream to use `/etc/resolv.conf` and `Network` defines a `Networkresolver`. You can specify one or both.

<9> You can specify two types of `upstreams`: `SystemResolvConf` or `Network`. `SystemResolvConf` configures the upstream to use `/etc/resolv.conf` and `Network` defines a `Networkresolver`. You can specify one or both.

kcarmichael08 · 2024-03-22T21:07:01Z

modules/nw-dns-loglevel.adoc


 [NOTE]
 ====
-The errors plugin is always enabled. The following `logLevel` settings report different error responses:
+The CoreDNS error log level is always enabled. The following log Level settings report different error responses:


should level be lower case?

kcarmichael08 · 2024-03-22T21:13:37Z

modules/nw-dns-operator-managementState.adoc

 +
 [source,terminal]
 ----
 oc patch dns.operator.openshift.io default --type merge --patch '{"spec":{"managementState":"Unmanaged"}}'
 ----
+
+. Review `managementState` of the DNS Operator using the `jq` command line JSON parser:


I saw this discussed recently - not sure if this is applicable to these docs or not, but I'll mention it just in case:

https://github.com/openshift/openshift-docs/blob/main/contributing_to_docs/doc_guidelines.adoc#commands-with-jq

@candita It looks like we avoid jq commands, when possible. Can you please suggest an alternative? Thanks!

@ahardin-rh you can use this instead

'''Review managementState of the DNS Operator using the jsonpath command line JSON parser:'''
oc get dns.operator.openshift.io default -ojsonpath='{.spec.managementState}'

Thank you! All updated.

kcarmichael08 · 2024-03-22T21:14:18Z

modules/nw-dns-operator-status.adoc


 You can inspect the status and view the details of the DNS Operator
 using the `oc describe` command.

 .Procedure

-View the status of the DNS Operator:
+. View the status of the DNS Operator:


Suggested change

. View the status of the DNS Operator:

* View the status of the DNS Operator:

kcarmichael08 · 2024-03-22T21:14:57Z

modules/nw-dns-operator-status.adoc

 [source,terminal]
 ----
 $ oc describe clusteroperators/dns
 ----
+
+Though the messages and spelling might vary from release to release, the expected status output looks like:


Suggested change

Though the messages and spelling might vary from release to release, the expected status output looks like:

Though the messages and spelling might vary in a specific release, the expected status output looks like:

kcarmichael08 · 2024-03-22T21:15:29Z

modules/nw-dns-operator.adoc

 ----
 +
-`AVAILABLE`, `PROGRESSING` and `DEGRADED` provide information about the status of the operator. `AVAILABLE` is `True` when at least 1 pod from the CoreDNS daemon set reports an `Available` status condition.
+`AVAILABLE`, `PROGRESSING` and `DEGRADED` provide information about the status of the operator. `AVAILABLE` is `True` when at least 1 pod from the CoreDNS daemon set reports an `Available` status condition, and the DNS service has a cluster IP address.


Suggested change

`AVAILABLE`, `PROGRESSING` and `DEGRADED` provide information about the status of the operator. `AVAILABLE` is `True` when at least 1 pod from the CoreDNS daemon set reports an `Available` status condition, and the DNS service has a cluster IP address.

`AVAILABLE`, `PROGRESSING`, and `DEGRADED` provide information about the status of the Operator. `AVAILABLE` is `True` when at least 1 pod from the CoreDNS daemon set reports an `Available` status condition, and the DNS service has a cluster IP address.

kcarmichael08 · 2024-03-22T21:17:06Z

modules/nw-dns-operatorloglevel.adoc

@@ -5,7 +5,7 @@
 [id="nw-dns-operatorloglevel_{context}"]
 = Setting the CoreDNS Operator log level

-Cluster administrators can configure the Operator log level to more quickly track down OpenShift DNS issues. The valid values for `operatorLogLevel` are `Normal`, `Debug`, and `Trace`. `Trace` has the most detailed information. The default `operatorlogLevel` is `Normal`. There are seven logging levels for issues: Trace, Debug, Info, Warning, Error, Fatal and Panic. After the logging level is set, log entries with that severity or anything above it will be logged.
+Log levels for CoreDNS and CoreDNS Operator are set in different manners. Cluster administrators can configure the Operator log level to more quickly track down OpenShift DNS issues. The valid values for `operatorLogLevel` are `Normal`, `Debug`, and `Trace`. `Trace` has the most detailed information. The default `operatorlogLevel` is `Normal`. There are seven logging levels for Operator issues: Trace, Debug, Info, Warning, Error, Fatal, and Panic. After the logging level is set, log entries with that severity or anything above it will be logged.


For some reason "in different manners" seems awkward - maybe "by using different methods"? It might just be me, so ignore if so. :)

modules/nw-dns-operatorloglevel.adoc

ahardin-rh · 2024-03-25T19:15:51Z

@kcarmichael08 Thank you for the excellent review feedback! 🚀 Updated. Just waiting for guidance on reworking the jq commands, if possible.

melvinjoseph86 · 2024-03-27T12:31:09Z

/label qe-approved

openshift-ci-robot · 2024-03-27T12:31:15Z

@ahardin-rh: This pull request references OSDOCS-8651 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.16.0" version, but no target version was set.

In response to this:

Version(s):
4.15+

Issue:
https://issues.redhat.com/browse/OSDOCS-8651

Link to docs preview:
https://73505--ocpdocs-pr.netlify.app/openshift-enterprise/latest/networking/dns-operator

QE review:

QE has approved this change.

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 · 2024-03-27T13:37:49Z

@ahardin-rh: This pull request references OSDOCS-8651 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.16.0" version, but no target version was set.

In response to this:

Version(s):
4.15+

Issue:
https://issues.redhat.com/browse/OSDOCS-8651

Link to docs preview:
https://73505--ocpdocs-pr.netlify.app/openshift-enterprise/latest/networking/dns-operator

QE review:

QE has approved this change.

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 · 2024-03-27T15:05:08Z

@ahardin-rh: 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/test-infra repository. I understand the commands that are listed here.

ahardin-rh · 2024-03-27T15:26:16Z

/cherrypick enterprise-4.15

ahardin-rh · 2024-03-27T15:26:23Z

/cherrypick enterprise-4.16

openshift-cherrypick-robot · 2024-03-27T15:27:04Z

@ahardin-rh: #73505 failed to apply on top of branch "enterprise-4.15":

Applying: OSDOCS-8651: Edits from content audit
.git/rebase-apply/patch:538: trailing whitespace.
$ oc get dns.operator.openshift.io default -ojsonpath='{.spec.managementState}' 
warning: 1 line adds whitespace errors.
Using index info to reconstruct a base tree...
M	modules/nw-dns-view.adoc
Falling back to patching base and 3-way merge...
Auto-merging modules/nw-dns-view.adoc
CONFLICT (content): Merge conflict in modules/nw-dns-view.adoc
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 OSDOCS-8651: Edits from content audit
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

In response to this:

/cherrypick enterprise-4.15

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.

openshift-cherrypick-robot · 2024-03-27T15:27:10Z

@ahardin-rh: #73505 failed to apply on top of branch "enterprise-4.16":

Applying: OSDOCS-8651: Edits from content audit
.git/rebase-apply/patch:538: trailing whitespace.
$ oc get dns.operator.openshift.io default -ojsonpath='{.spec.managementState}' 
warning: 1 line adds whitespace errors.
Using index info to reconstruct a base tree...
M	modules/nw-dns-view.adoc
Falling back to patching base and 3-way merge...
Auto-merging modules/nw-dns-view.adoc
CONFLICT (content): Merge conflict in modules/nw-dns-view.adoc
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 OSDOCS-8651: Edits from content audit
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

In response to this:

/cherrypick enterprise-4.16

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.

candita · 2024-03-27T15:34:59Z

/assign @gcs278

openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Mar 20, 2024

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 Mar 20, 2024

ahardin-rh changed the title ~~[WIP}OSDOCS-8651: Edits from content audit~~ [WIP]OSDOCS-8651: Edits from content audit Mar 20, 2024

ahardin-rh added this to the Continuous Release milestone Mar 20, 2024

openshift-ci bot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Mar 20, 2024

ahardin-rh added branch/enterprise-4.15 branch/enterprise-4.16 and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Mar 20, 2024

ocpdocs-vale-bot reviewed Mar 20, 2024

View reviewed changes

modules/nw-controlling-dns-pod-placement.adoc Outdated Show resolved Hide resolved

ahardin-rh force-pushed the DNS-operator-edits branch from 6d63105 to 60a0549 Compare March 21, 2024 19:51

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

ocpdocs-vale-bot reviewed Mar 21, 2024

View reviewed changes

modules/nw-dns-operatorloglevel.adoc Outdated Show resolved Hide resolved

ahardin-rh force-pushed the DNS-operator-edits branch from 60a0549 to 2a43572 Compare March 22, 2024 13:11

ahardin-rh self-assigned this Mar 22, 2024

ahardin-rh changed the title ~~[WIP]OSDOCS-8651: Edits from content audit~~ OSDOCS-8651: Edits from content audit Mar 22, 2024

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 Mar 22, 2024

ahardin-rh requested review from candita and melvinjoseph86 March 22, 2024 14:45

ahardin-rh added the peer-review-needed Signifies that the peer review team needs to review this PR label Mar 22, 2024

openshift-ci bot assigned candita Mar 22, 2024

kcarmichael08 added peer-review-in-progress Signifies that the peer review team is reviewing this PR and removed peer-review-needed Signifies that the peer review team needs to review this PR labels Mar 22, 2024

kcarmichael08 reviewed Mar 22, 2024

View reviewed changes

kcarmichael08 added the peer-review-done Signifies that the peer review team has reviewed this PR label Mar 22, 2024

kcarmichael08 removed the peer-review-in-progress Signifies that the peer review team is reviewing this PR label Mar 22, 2024

ahardin-rh force-pushed the DNS-operator-edits branch from 2a43572 to 53891a2 Compare March 25, 2024 19:04

ocpdocs-vale-bot reviewed Mar 25, 2024

View reviewed changes

modules/nw-dns-operatorloglevel.adoc Show resolved Hide resolved

openshift-ci bot added the qe-approved Signifies that QE has signed off on this PR label Mar 27, 2024

OSDOCS-8651: Edits from content audit

3214b39

ahardin-rh force-pushed the DNS-operator-edits branch from 53891a2 to 3214b39 Compare March 27, 2024 14:56

ahardin-rh merged commit 8bcfc5d into openshift:main Mar 27, 2024
2 checks passed

openshift-ci bot assigned gcs278 Mar 27, 2024

This was referenced Mar 27, 2024

[enterprise-4.15]OSDOCS-8651: Edits from content audit #73815

Merged

[enterprise-4.16]OSDOCS-8651: Edits from content audit #73822

Merged

ahardin-rh mentioned this pull request Apr 4, 2024

OSDOCS-8651: Revert "OSDOCS-8651: Edits from content audit" for 4.15 #74185

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

OSDOCS-8651: Edits from content audit #73505

OSDOCS-8651: Edits from content audit #73505

ahardin-rh commented Mar 20, 2024 •

edited

Loading

openshift-ci-robot commented Mar 20, 2024 •

edited by openshift-ci bot

Loading

ocpdocs-previewbot commented Mar 20, 2024 •

edited

Loading

openshift-ci-robot commented Mar 22, 2024 •

edited by openshift-ci bot

Loading

ahardin-rh commented Mar 22, 2024

candita commented Mar 22, 2024

openshift-ci-robot commented Mar 22, 2024 •

edited by openshift-ci bot

Loading

kcarmichael08 left a comment

kcarmichael08 Mar 22, 2024

kcarmichael08 Mar 22, 2024

kcarmichael08 Mar 22, 2024

kcarmichael08 Mar 22, 2024

kcarmichael08 Mar 22, 2024

kcarmichael08 Mar 22, 2024

ahardin-rh Mar 25, 2024

melvinjoseph86 Mar 27, 2024 •

edited

Loading

ahardin-rh Mar 27, 2024

kcarmichael08 Mar 22, 2024

kcarmichael08 Mar 22, 2024

kcarmichael08 Mar 22, 2024

kcarmichael08 Mar 22, 2024

ahardin-rh commented Mar 25, 2024

melvinjoseph86 commented Mar 27, 2024

openshift-ci-robot commented Mar 27, 2024 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Mar 27, 2024 •

edited by openshift-ci bot

Loading

openshift-ci bot commented Mar 27, 2024

ahardin-rh commented Mar 27, 2024

ahardin-rh commented Mar 27, 2024

openshift-cherrypick-robot commented Mar 27, 2024

openshift-cherrypick-robot commented Mar 27, 2024

candita commented Mar 27, 2024


		As a cluster administrator, you can use a custom node selector to configure the daemon set for CoreDNS to run or not run on certain nodes.
		Though not a common operation, you might find a need to control which nodes have CoreDNS pods assigned and running. For example, if the cluster administrator has configured security policies that can prohibit communication between pairs of nodes, that would necessitate restricting the set of nodes on which the daemonset for CoreDNS runs. If DNS pods are running on some nodes in the cluster and the nodes where DNS pods are not running have network connectivity to nodes where DNS pods are running, DNS service will be available to all pods.

	<9> You can specify two types of `upstreams` - `SystemResolvConf` or `Network`. `SystemResolvConf` configures the upstream to use `/etc/resolv.conf` and `Network` defines a `Networkresolver`. You can specify one or both.
	<9> You can specify two types of `upstreams`: `SystemResolvConf` or `Network`. `SystemResolvConf` configures the upstream to use `/etc/resolv.conf` and `Network` defines a `Networkresolver`. You can specify one or both.

	. View the status of the DNS Operator:
	* View the status of the DNS Operator:

	Though the messages and spelling might vary from release to release, the expected status output looks like:
	Though the messages and spelling might vary in a specific release, the expected status output looks like:

	`AVAILABLE`, `PROGRESSING` and `DEGRADED` provide information about the status of the operator. `AVAILABLE` is `True` when at least 1 pod from the CoreDNS daemon set reports an `Available` status condition, and the DNS service has a cluster IP address.
	`AVAILABLE`, `PROGRESSING`, and `DEGRADED` provide information about the status of the Operator. `AVAILABLE` is `True` when at least 1 pod from the CoreDNS daemon set reports an `Available` status condition, and the DNS service has a cluster IP address.

OSDOCS-8651: Edits from content audit #73505

OSDOCS-8651: Edits from content audit #73505

Conversation

ahardin-rh commented Mar 20, 2024 • edited Loading

openshift-ci-robot commented Mar 20, 2024 • edited by openshift-ci bot Loading

ocpdocs-previewbot commented Mar 20, 2024 • edited Loading

openshift-ci-robot commented Mar 22, 2024 • edited by openshift-ci bot Loading

ahardin-rh commented Mar 22, 2024

candita commented Mar 22, 2024

openshift-ci-robot commented Mar 22, 2024 • edited by openshift-ci bot Loading

kcarmichael08 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

melvinjoseph86 Mar 27, 2024 • edited Loading

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

ahardin-rh commented Mar 25, 2024

melvinjoseph86 commented Mar 27, 2024

openshift-ci-robot commented Mar 27, 2024 • edited by openshift-ci bot Loading

openshift-ci-robot commented Mar 27, 2024 • edited by openshift-ci bot Loading

openshift-ci bot commented Mar 27, 2024

ahardin-rh commented Mar 27, 2024

ahardin-rh commented Mar 27, 2024

openshift-cherrypick-robot commented Mar 27, 2024

openshift-cherrypick-robot commented Mar 27, 2024

candita commented Mar 27, 2024

ahardin-rh commented Mar 20, 2024 •

edited

Loading

openshift-ci-robot commented Mar 20, 2024 •

edited by openshift-ci bot

Loading

ocpdocs-previewbot commented Mar 20, 2024 •

edited

Loading

openshift-ci-robot commented Mar 22, 2024 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Mar 22, 2024 •

edited by openshift-ci bot

Loading

melvinjoseph86 Mar 27, 2024 •

edited

Loading

openshift-ci-robot commented Mar 27, 2024 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Mar 27, 2024 •

edited by openshift-ci bot

Loading