gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: * See this link:https://github.com/openshift/rosa/blob/master/cmd/create/network/templates/rosa-quickstart-default-vpc/cloudformation.yaml[default VPC AWS CloudFormation template] for more information.
Revised: * See the link:https://github.com/openshift/rosa/blob/master/cmd/create/network/templates/rosa-quickstart-default-vpc/cloudformation.yaml[default VPC AWS CloudFormation template] for more information.
Original: The command takes about 5 minutes to run and provides regular status updates from AWS as resources are created. If there is an issue with CloudFormation, a rollback is attempted. For all other errors are encountered, please follow the error message instructions or contact AWS support.
Revised: The command takes about 5 minutes to run and provides regular status updates from AWS as resources are created. If there is an issue with CloudFormation, a rollback is attempted. For all other errors that are encountered, please follow the error message instructions or contact AWS support.
Original: ifndef::node-tuning-operator[]
The following types of configuration changes typically require a reboot:

* Updates to tuning profiles that modify kernel parameters or system behavior.node-tuning-operator
* Kubelet configuration updates.
* Node-level changes delivered through `MachineConfig`, such as `sysctl` settings or system service changes.
endif::[]

TALM ensures that only nodes with a degraded tuned profile, indicating a reboot is needed, are rebooted.

Instead of rebooting nodes after each individual change, you can apply all configuration updates through policies and then trigger a single, coordinated reboot. 
Revised: ifdef::ztp[]
The following types of configuration changes typically require a reboot:

* Updates to tuning profiles that modify kernel parameters or system behavior.node-tuning-operator
* Kubelet configuration updates.
* Node-level changes delivered through `MachineConfig`, such as `sysctl` settings or system service changes.
endif::ztp[]
Original: [id="ztp-coordinating-reboots-for-config-changes_{context}"]
= Coordinating reboots for configuration changes
Revised: :_mod-docs-content-type: PROCEDURE
[id="ztp-coordinating-reboots-for-config-changes_{context}"]
ifndef::ztp[]
= Coordinating reboots for tuning profile changes
endif::ztp[]

ifdef::ztp[]
= Coordinating reboots for configuration changes
endif::ztp[]
Original: . After you apply the CGU custom resource, {cgu-operator} rolls out the configuration policies in order. Once all policies are compliant, it applies the reboot policy and triggers a reboot of all nodes in the specified `MachineConfigPool`.
Revised: . Apply the CGU CR by entering the following command:

[source,terminal]
$ oc apply -f <cgu_cr>.yaml

After you apply the CGU custom resource, {cgu-operator} rolls out the configuration policies in order. Once all policies are compliant, it applies the reboot policy and triggers a reboot of all nodes in the specified machine config pool.
Original: * With this update, {pipelines-title} version 1.14.6 supports {OCP} versions 4.12, 4.13, 4.14, 4.15, 4.16, 4.17 and 4.18.
Revised: * With this update, {pipelines-title} version 1.14.6 supports {OCP} versions 4.12, 4.13, 4.14, 4.15, 4.16, 4.17, and 4.18.
Original: With the introduction of {product-title} 4.19, package-based {op-system-base} worker nodes are no longer supported. Attempting to update your cluster while having these nodes up and running will prevent you from successfully completing the update.
Revised: With the introduction of {product-title} 4.19, package-based {op-system-base} worker nodes are no longer supported. If you try to update your cluster while those nodes are up and running, the update will fail.
Original: With the introduction of {product-title} 4.19, package-based {op-system-base} worker nodes are no longer supported. The following procedure describes how to identify {op-system-base} nodes for cluster removal on bare-metal installations. You must perform the steps described in this procedure in order to ensure a successful cluster update.
Revised: With the introduction of {product-title} 4.19, package-based {op-system-base} worker nodes are no longer supported. The following procedure describes how to identify {op-system-base} nodes for cluster removal on bare-metal installations. You must complete the following steps to successfully update your cluster.
Original: . xref:../../nodes/nodes/nodes-nodes-working.adoc#nodes-nodes-working-deleting-bare-metal_nodes-nodes-working[Continue with the node removal process]. {op-system-base} nodes are not managed by the Machine API and have no compute machine sets associated with them. You must unschedule and drain the node before manually deleting it from the cluster.
Revised: . xref:../../nodes/nodes/nodes-nodes-working.adoc#nodes-nodes-working-deleting-bare-metal_nodes-nodes-working[Continue with the node removal process]. {op-system-base} nodes are not managed by the Machine API and have no compute machine sets associated with them. You must unschedule and drain the node before you manually delete it from the cluster.
Original: For more information on this process, see link:https://access.redhat.com/solutions/4976801[How to remove a worker node from Red{nbsp}Hat {product-title} 4 UPI?].
Revised: For more information on this process, see link:https://access.redhat.com/solutions/4976801[How to remove a worker node from Red{nbsp}Hat {product-title} 4 UPI?]
Original: . Create a compressed file from the `must-gather` directory that was just created in your working directory. For example, on a computer that uses a Linux operating system, run the following command:
Revised: . Create a compressed file from the `must-gather` directory that was just created in your working directory. Make sure you provide the date and cluster ID for a unique must-gather data. For more information about how to find the cluster ID, see link:https://access.redhat.com/solutions/5280291[How to find the cluster-id or name on OpenShift cluster]. For example, on a computer that uses a Linux operating system, run the following command:
Original: . Create a compressed file from the `must-gather` directory that was just created in your working directory. For example, on a computer that uses a Linux operating system, run the following command:
$ tar cvaf must-gather.tar.gz must-gather.local.472290403699006248 <1>
Revised: $ tar cvaf must-gather-`date +"%m-%d-%Y-%H-%M-%S"`-<cluster_id>.tar.gz <must_gather_local_dir> <1>
Original: . Create a compressed file from the `must-gather` directory that was just created in your working directory. For example, on a computer that uses a Linux
$ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/ <1>
<1> Make sure to replace `must-gather-local.5421342344627712289/` with the
Revised: <1> Make sure to replace `<must_gather_local_dir>` with the actual directory name.
Original: . Create a compressed file from the `must-gather` directory that was just created in your working directory. For example, on a computer that uses a Linux operating system, run the following command:
Revised: . Create a compressed file from the `must-gather` directory that was just created in your working directory. Make sure you provide the date and cluster ID for the unique must-gather data. For more information about how to find the cluster ID, see link:https://access.redhat.com/solutions/5280291[How to find the cluster-id or name on OpenShift cluster]. For example, on a computer that uses a Linux operating system, run the following command:
Original: - matchers:
- "service=<your_service>" # <5>
routes:
- matchers:
- <your_matching_rules> # <6>
receiver: <receiver> # <7>
- name: <receiver>
<receiver_configuration> # <8>
<5> Specify the name of the service that fires the alerts.
<6> Specify labels to match your alerts.
<7> Specify the name of the receiver to use for the alerts.
<8> Specify the receiver configuration.
[IMPORTANT]
====
* Use the `matchers` key name to indicate the matchers that an alert has to fulfill to match the node.
Do not use the `match` or `match_re` key names, which are both deprecated and planned for removal in a future release.
Revised: <1> The receiver's name.
Original: - matchers:
- "service=<your_service>" # <5>
routes:
- matchers:
- <your_matching_rules> # <6>
receiver: <receiver> # <7>
- name: <receiver>
<receiver_configuration> # <8>
<5> Specify the name of the service that fires the alerts.
<6> Specify labels to match your alerts.
<7> Specify the name of the receiver to use for the alerts.
<8> Specify the receiver configuration.
[IMPORTANT]
====
* Use the `matchers` key name to indicate the matchers that an alert has to fulfill to match the node.
Do not use the `match` or `match_re` key names, which are both deprecated and planned for removal in a future release.
Revised: <2> The receiver configuration. The supported receivers are PagerDuty, webhook, email, Slack, Microsoft Teams and etc.
Original: You can configure Alertmanager to send notifications. Customize where and how Alertmanager sends notifications about default platform alerts by editing the default configuration in the `alertmanager-main` secret in the `openshift-monitoring` namespace.
Revised: You can configure Alertmanager to send notifications for important alerts coming from your cluster. Customize where and how Alertmanager sends notifications about default platform alerts by editing the default configuration in the `alertmanager-main` secret in the `openshift-monitoring` namespace.
Original: routes:
receivers:
- name: default
- name: watchdog
- name: team-frontend-page
pagerduty_configs:
- service_key: "<your_key>"
http_config: # <2>
proxy_from_environment: true
authorization:
credentials: xxxxxxxxxx
<1> Alerts of `critical` severity that are fired by the `example-app` service are sent through the `team-frontend-page` receiver. Typically, these types of alerts would be paged to an individual or a critical response team.
<2> Custom HTTP configuration for a specific receiver. If you configure the custom HTTP configuration for a specific alert receiver, that receiver does not inherit the global HTTP config settings.
Revised: <2> You can create routes within other routes for more complex alert routing.
In this example, alerts of critical severity from the `example-app` service are routed to the `team-frontend-page` receiver. These alerts are typically paged to an individual or critical response team.
Original: routes:
receivers:
- name: default
- name: watchdog
- name: team-frontend-page
pagerduty_configs:
- service_key: "<your_key>"
http_config: # <2>
proxy_from_environment: true
authorization:
credentials: xxxxxxxxxx
<1> Alerts of `critical` severity that are fired by the `example-app` service are sent through the `team-frontend-page` receiver. Typically, these types of alerts would be paged to an individual or a critical response team.
<2> Custom HTTP configuration for a specific receiver. If you configure the custom HTTP configuration for a specific alert receiver, that receiver does not inherit the global HTTP config settings.

** To apply the changes from the CLI, run the following command:
** To apply the changes from the {product-title} web console, click *Save*.
Revised: . Verify your routing configuration by using the routing tree visualization. Visualize the routing tree by running the following command:
Original: . Open the Alertmanager YAML configuration file:

** To open the Alertmanager configuration from the CLI:

.. Print the currently active Alertmanager configuration from the `alertmanager-main` secret into `alertmanager.yaml` file:
.. Open the `alertmanager.yaml` file.
** To open the Alertmanager configuration from the {product-title} web console:
Revised: . Edit the Alertmanager configuration.
Original: * IPsec is not supported on {op-system-base-full} compute nodes because of a `libreswan` incompatiblility issue between a host and an `ovn-ipsec` container that exist in each compute node. See (link:https://issues.redhat.com/browse/OCPBUGS-52949[*OCPBUGS-52949*]).
Revised: * IPsec is not supported on {op-system-base-full} compute nodes because of a `libreswan` incompatiblility issue between a host and an `ovn-ipsec` container that exist in each compute node. (link:https://issues.redhat.com/browse/OCPBUGS-52949[*OCPBUGS-52949*]).
Original: * Previously, selecting the *All projects* option on the *VolumeSnapshot* page of the web console in the *Administrator* perspective resulted in a `404: Page Not Found` error. With this release, a fix ensures that when you select the *All projects* option on the *VolumeSnapshot* page, the page shows results as expected without a `404: Page Not Found` error showing on the page. (link:https://issues.redhat.com/browse/OCPBUGS-54269[*OCPBUGS-54269*])
Revised: * Previously, selecting the *All projects* option on the *VolumeSnapshot* page of the web console in the *Administrator* perspective resulted in a `404: Page Not Found` error. With this release, a fix ensures that when you select the *All projects* option on the *VolumeSnapshot* page, the page shows results as expected without an error. (link:https://issues.redhat.com/browse/OCPBUGS-54269[*OCPBUGS-54269*])
Original: * Previously, when you ran the `oc-mirror --v2 version` command, the output was missing the version information. With this release, the output from the command now correctly shows the version number. (link:https://issues.redhat.com/browse/OCPBUGS-53388[*OCPBUGS-53388*])
Revised: * Previously, the output of the `oc-mirror --v2 version` command was missing the version information. With this release, the output from the command now correctly shows the version number. (link:https://issues.redhat.com/browse/OCPBUGS-53388[*OCPBUGS-53388*])
Original: * Previously, an update to the {ibm-cloud-name} Cloud Internet Services (CIS) implementation impacted the upstream Terraform plugin. If you attempted to create an external-facing cluster on {ibm-cloud-name}, the following error was outputted:
Revised: * Previously, an update to the {ibm-cloud-name} Cloud Internet Services (CIS) implementation impacted the upstream Terraform plugin. If you attempted to create an external-facing cluster on {ibm-cloud-name}, the following error occurred:
Original: With this release, a fix to the upstream Terrafrom version means that you can use the installation program to create an external cluster on {product-title} without the plugin issue occuring. (link:https://issues.redhat.com/browse/OCPBUGS-53453[*OCPBUGS-53453*])
Revised: With this release, you can use the installation program to create an external cluster on {product-title} without the plugin issue. (link:https://issues.redhat.com/browse/OCPBUGS-53453[*OCPBUGS-53453*])
Original: * Previously, the Container Storage Interface (CSI) driver for the {gcp-first} persistent disk (PD) did not support the `hyperdisk-balanced` volume type when the `ReadWriteMany` (RWX) access mode was set. If you attempted to provision a `hyperdisk-balanced` volume with this configuration, an error was outputted that suggested mounting the volume with RWX access mode enabled was not possible. With this release, a fix ensures that you can now mount a `hyperdisk-balanced` volume when the RWX access mode is enabled so that this issue no longer persists. See the {gcp-short} documentation for further limitations when using Hyperdisk volumes in multi-writer mode. (link:https://issues.redhat.com/browse/OCPBUGS-44769[*OCPBUGS-44769*])
Revised: * Previously, the Container Storage Interface (CSI) driver for the {gcp-first} persistent disk (PD) did not support the `hyperdisk-balanced` volume type when the `ReadWriteMany` (RWX) access mode was set. If you attempted to provision a `hyperdisk-balanced` volume with this configuration, an error occurred that suggested mounting the volume with RWX access mode enabled was not possible. With this release, you can now mount a `hyperdisk-balanced` volume when the RWX access mode is enabled so that this issue no longer persists. See the {gcp-short} documentation for further limitations when using Hyperdisk volumes in multi-writer mode. (link:https://issues.redhat.com/browse/OCPBUGS-44769[*OCPBUGS-44769*])
Original: If you added a `NoSchedule` taint to the infrastructure node, any pods that are controlled by a daemon set on that node are marked as `misscheduled`. You must either delete the pods or add a toleration to the pods as shown in the Red Hat Knowledgebase solution link:https://access.redhat.com/solutions/6592171[add toleration on `misscheduled` DNS pods]. Note that you cannot add a toleration to a daemon set object that is managed by an operator.
Revised: If you added a `NoSchedule` taint to the infrastructure node, any pods that are controlled by a daemon set on that node are marked as `misscheduled`. You must either delete the pods or add a toleration to the pods, as shown in the Red{nbsp}Hat Knowledgebase solution link:https://access.redhat.com/solutions/6592171[Openshift-dns daemonsets doesn't include toleration to run on nodes with taints]. You cannot add a toleration to a daemon set object that is managed by an Operator.
Original: * Currently, when the OpenShift tenancy mode is enabled, the ServiceAccount of the gateway component of a TempoStack or TempoMonolithic instance requires the TokenReview and SubjectAccessReview permissions for authorization.
Revised: * Currently, when the OpenShift tenancy mode is enabled, the `ServiceAccount` object of the gateway component of a `TempoStack` or `TempoMonolithic` instance requires the `TokenReview` and `SubjectAccessReview` permissions for authorization.
Original: * With this update, for a user to create or modify a `TempoStack` or `TempoMonolithic` custom resource with enabled multi-tenancy, the user must have permissions to create a TokenReview and SubjectAccessReview.
Revised: * With this update, for a user to create or modify a `TempoStack` or `TempoMonolithic` custom resource with enabled multi-tenancy, the user must have permissions to create the `TokenReview` and `SubjectAccessReview` permissions for authorization.
Original: * There is currently a known issue that assigns a lower `SecurityContextConstraints` (SCC) to Redis service account in {gitops-shortname} v1.16 after upgrading from {gitops-shortname} v1.15 to v1.16. The {gitops-shortname} Operator does not update the `securityContext` of the `redis-ha-server` StatefulSet, which causes the container's user to be statically set instead of being randomly assigned as required by the `restricted-v2` SCC. The `redis-ha-server` StatefulSet pods retain the old configurations and are not updated with the new settings. As a result, the new configuration of the StatefulSet is not applied correctly.
Workaround: Manually delete the `redis-ha-server` StatefulSet to trigger the re-creation of the pods with the updated settings. link:https://issues.redhat.com/browse/GITOPS-6670[GITOPS-6670]
Revised: Workaround: Manually delete the `redis-ha-server` `StatefulSet` to trigger the re-creation of the pods with the updated settings. link:(https://issues.redhat.com/browse/GITOPS-6670)[GITOPS-6670]
Original: Once your agents are approved, you can scale the nodepools. agentLabelSelector configured in nodepool ensures that only matching agents added to the cluster. This also aids in descaling the nodepool. To remove specific architecture nodes from the cluster, you can descale the corresponding nodepool.
Revised: After your agents are approved, you can scale the node pools, `agentLabelSelector` configured in the node pool ensures that only matching agents added to the cluster. This also aids in descaling the node pool. To remove specific architecture nodes from the cluster, descale the corresponding node pool.
Original: This will create a nodepool of architecture `ppc64le` with zero replicas.
+
[source,terminal]
----
agentLabelSelector:
    matchLabels:
        inventory.agent-install.openshift.io/cpu-architecture: ppc64le
----
+
This selector block is used to select the agents which are matching the given label. Which will ensure it will select only the agents from `ppc64le` architecture when it is scaled.
Revised: . To create a node pool of architecture `ppc64le` with zero replicas, see the following configuration:

[source,yaml]
# ...
agentLabelSelector:
matchLabels:
inventory.agent-install.openshift.io/cpu-architecture: ppc64le
# ...
Original: For heterogeneous nodepools, you need to create infraenv for each architecture you are going to have in your HCP. i.e. for heterogeneous nodepools with `x86_64` and `ppc64le` architecture, you will need to create two infraenvs with both architectures.
Revised: For heterogeneous node pools, you must create the `infraenv` custom resource (CR) for each architecture. For example, for node pools with `x86_64` and `ppc64le` architectures, create the `infraenv` CR for `x86_64` and `ppc64le`.
Original: This will create two infraenvs with `x86_64` & `ppc64le` architectures. Before proceeding, make sure that the OS images for both architectures are added to the `AgentServiceConfig`. After this you can use the above infraenvs to get the minimal iso and follow the `create-agent-cluster.md` to add them to your cluster as agents.
Revised: This creates two `infraenv` resources with `x86_64` and `ppc64le` architectures. Before proceeding, make sure that the OS images for both architectures are added to the `AgentServiceConfig` resource. After this you can use the above infraenvs to get the minimal iso and follow the `create-agent-cluster.md` to add them to your cluster as agents.
Original: You can point `*.apps.<cluster_name>` record to either one of the worker nodes where ingress application is hosted, or if you are able to set up a load balancer on top of the worker nodes, point this record to this load balancer. When you are creating a heterogeneous nodepool, please make sure the workers are reachable from each other or keep them in the same network.
Revised: You can point `*.apps.<cluster_name>` record to either one of the worker nodes where ingress application is hosted, or if you are able to set up a load balancer on top of the worker nodes, point this record to this load balancer. When you are creating a heterogeneous nodepool, make sure the workers are reachable from each other or keep them in the same network.
Original: You can point `*.apps.<cluster_name>` record to either one of the worker nodes where ingress application is hosted, or if you are able to set up a load balancer on top of the worker nodes, point this record to this load balancer. When you are creating a heterogeneous nodepool, make sure the workers are reachable from each other or keep them in the same network.
Revised: You can point an `*.apps.<cluster_name>` record to either one of the worker nodes where ingress application is hosted. Or, if you are able to set up a load balancer on top of the worker nodes, point this record to this load balancer. When you are creating a heterogeneous nodepool, make sure the workers are reachable from each other or keep them in the same network.
Original: Use a multi-architecture release image when creating the cluster to enable support for heterogeneous node pools. Find the latest multi architecture images from link:https://multi.ocp.releases.ci.openshift.org/[here].
Revised: Use a multi-architecture release image when creating the cluster to enable support for heterogeneous node pools. Find the latest multi architecture images on the link:https://multi.ocp.releases.ci.openshift.org/[[Multi-arch release images] page .
Original: This creates two `infraenv` resources with `x86_64` and `ppc64le` architectures. Before proceeding, make sure that the OS images for both architectures are added to the `AgentServiceConfig` resource. After this you can use the above infraenvs to get the minimal iso and follow the `create-agent-cluster.md` to add them to your cluster as agents.
Revised: These commands creates two `infraenv` resources with `x86_64` and `ppc64le` architectures. Before proceeding, make sure that the OS images for both architectures are added to the `AgentServiceConfig` resource. After this, you can use the above `infraenv` resources to get the minimal ISO image. Then, follow the `create-agent-cluster.md` to add them to your cluster as agents.