gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: * Previously, an Operator updated the 'Progressing' condition's `lastTransitionTime` value even when the condition's status did not actually change. This led to potential installation errors and perceived instability for end users. With this release, the Operator is prevented from updating the `lastTransitionTime` value unless there is a status change. This enhances Operator stability, minimizes installer errors, and ensures a smoother user experience. (link:https://issues.redhat.com/browse/OCPBUGS-55782[OCPBUGS-55782])
Revised: * Previously, an Operator updated the `Progressing` condition's `lastTransitionTime` value even when the condition's status did not actually change. This led to potential installation errors and perceived instability for end users. With this release, the Operator is prevented from updating the `lastTransitionTime` value unless there is a status change. This enhances Operator stability, minimizes installer errors, and ensures a smoother user experience. (link:https://issues.redhat.com/browse/OCPBUGS-55782[OCPBUGS-55782])
Original: * Previously, when adding a node in a disconnected environment, private registry images were inaccessible for the `oc adm node-image` command. As a result, issues with pulling images prevented adding a node. This error only occurs if the cluster is initially installed with an installation program binary downloaded from mirror.openshift.com. The issue is resolved in this release. (link:https://issues.redhat.com/browse/OCPBUGS-55449[OCPBUGS-55449])
Revised: * Previously, when adding a node in a disconnected environment, private registry images were inaccessible for the `oc adm node-image` command. As a result, issues with pulling images prevented adding a node. This error only occurs if the cluster is initially installed with an installation program binary downloaded from `\mirror.openshift.com`. The issue is resolved in this release. (link:https://issues.redhat.com/browse/OCPBUGS-55449[OCPBUGS-55449])
Original: * Previously, {azure-first} Spot Virtual Machines (VMs) that were evicted before their node became ready, could get stuck in the 'provisioned' state. With this release, {azure-short} Spot VMs now use a delete eviction policy, ensuring that the VMs correctly transition to the 'failed' state if they are preempted. (link:https://issues.redhat.com/browse/OCPBUGS-55373[OCPBUGS-55373])
Revised: * Previously, {azure-first} Spot Virtual Machines (VMs) that were evicted before their node became ready could get stuck in the `provisioned` state. With this release, {azure-short} Spot VMs now use a delete eviction policy, ensuring that the VMs correctly transition to the `failed` state if they are preempted. (link:https://issues.redhat.com/browse/OCPBUGS-55373[OCPBUGS-55373])
Original: * Previously, an image pull secret generated for the internal image registry wwas not regenerated until after the embedded credentials had expired. This resulted in a small period of time during which the image pull secrets were invalid. With this release, the image pull secrets are refreshed before the embedded credentials expire. (link:https://issues.redhat.com/browse/OCPBUGS-54304[OCPBUGS-54304])
Revised: * Previously, an image pull secret generated for the internal image registry was not regenerated until after the embedded credentials expired. This resulted in a small period of time during which the image pull secrets were invalid. With this release, the image pull secrets are refreshed before the embedded credentials expire. (link:https://issues.redhat.com/browse/OCPBUGS-54304[OCPBUGS-54304])
Original: * Previously, when adding a node in a disconnected environment, private registry images were inaccessible for the `oc adm node-image` command. As a result, issues with pulling images prevented adding a node. This error only occurs if the cluster is initially installed with an installation program binary downloaded from `\mirror.openshift.com`. The issue is resolved in this release. (link:https://issues.redhat.com/browse/OCPBUGS-55449[OCPBUGS-55449])
Revised: * Previously, when adding a node in a disconnected environment, private registry images were inaccessible for the `oc adm node-image` command. As a result, issues with pulling images prevented adding a node. This error only occurs if the cluster is initially installed with an installation program binary downloaded from `mirror.openshift.com`. The issue is resolved in this release. (link:https://issues.redhat.com/browse/OCPBUGS-55449[OCPBUGS-55449])
Original: * Check the status of your NAT gateway. A status of `Pending`, `Available`, or `Deleting` counts against your quota. If you've recently deleted an NAT gateway, wait a few minutes for the status to go from `Deleting` to `Deleted`. Then try creating a new NAT gateway.
Revised: * Check the status of your NAT gateway. A status of `Pending`, `Available`, or `Deleting` counts against your quota. If you've recently deleted a NAT gateway, wait a few minutes for the status to go from `Deleting` to `Deleted`. Then try creating a new NAT gateway.
Original: * Clean unused VPCs. Before you can delete a VPC, you must first terminate or delete any resources that created a requester-managed network interface in the VPC. For example, you must terminate your EC2 instances and delete your load balancers, NAT gateways, transit gateways, and interface VPC endpoints.
Revised: * Clean unused VPCs. Before you can delete a VPC, you must first terminate or delete any resources that created a requester-managed network interface in the VPC. For example, you must terminate your EC2 instances and delete your load balancers, NAT gateways, transit gateways, and interface VPC endpoints before deleting a VPC.
Original: .. Terminate all instances in the VPC. For more information, see https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html[Terminate Your Instance].
Revised: .. Terminate all instances in the VPC. For more information, see https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html[Terminate Amazon EC2 instances].
Original: For more information about list-attached-role-policies command, https://docs.aws.amazon.com/cli/latest/reference/iam/list-attached-role-policies.html[list-attached-role-policies] in the official AWS documentation.
Revised: For more information about the list-attached-role-policies command, see https://docs.aws.amazon.com/cli/latest/reference/iam/list-attached-role-policies.html[list-attached-role-policies] in the official AWS documentation.
Original: . Start by checking if EBS encryption is enabled in the EC2 settings. You can check the status for that by following the steps in https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default[AWS Check EBS Encryption].
Revised: . Start by checking if EBS encryption is enabled in the EC2 settings. You can check the status by following the steps in https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default[AWS Check EBS Encryption].
Original: . If none of this works, disable EBS encryption entirely. If this is still a requirement you can't disable, you can specify a customer-managed-key during ROSA install following the steps in https://cloud.redhat.com/experts/rosa/kms/?extIdCarryOver=true&sc_cid=701f2000001Css5AAC[Creating a ROSA cluster in STS mode with custom KMS key].
Revised: . If the previous two steps failed to fix the issue, disable EBS encryption entirely. If this is a requirement you cannot disable, you can specify a customer-managed-key during ROSA install following the steps in https://cloud.redhat.com/experts/rosa/kms/?extIdCarryOver=true&sc_cid=701f2000001Css5AAC[Creating a ROSA cluster in STS mode with custom KMS key].
Original: The problem occurs because a previous cluster did not have had its Route 53 hosted zone removed on uninstallation. As a result, the previously created Route 53 entries were still there and are now conflicting with the cluster's DNS.
Revised: The problem occurs because a previous cluster did not have its Route 53 hosted zone removed during uninstallation. As a result, the existing Route 53 entries are conflicting with the cluster's DNS.
Original: Normally, this validation gets completed within 15 minutes, but in some cases it can take up to 4 hours for AWS to validate. In order to attempt successful provisioning, Red{nbsp} have configured our installer to reattempt installation if this issue occurs but the installation can still fail if the validation takes more time or if the validation itself fails.
Revised: Normally, this validation gets completed within 15 minutes, but in some cases it can take up to 4 hours for AWS to validate. In order to attempt successful provisioning, Red{nbsp}Hat has configured our installer to reattempt installation if this issue occurs, but the installation can still fail if the validation continues to time out or if the validation itself fails.
Original: This error indicates the cluster's installation was blocked as the installer was unable to create Route 53 hosted zone. A hosted zone is a container for records, and records contain information about how you want to route traffic for a specific domain, such as example.com, and its subdomains (acme.example.com, zenith.example.com).
Revised: This error indicates the cluster's installation was blocked as the installer was unable to create a Route 53 hosted zone. A hosted zone is a container for records, and records contain information about how you want to route traffic for a specific domain, such as example.com, and its subdomains (acme.example.com, zenith.example.com).
Original: * To fix this issue, check your subnets provided in the `platform.aws.subnets` parameter during installation. The subnets must be a part of the same machine Network CIDR ranges that you specify. For a standard cluster, specify a public and a private subnet for each availability zone. For a private cluster, specify a private subnet for each availability zone.
Revised: * Check your subnets provided in the `platform.aws.subnets` parameter during installation. The subnets must be a part of the same machine Network CIDR ranges that you specify.
** For a standard cluster, specify a public and a private subnet for each availability zone.
** For a private cluster, specify a private subnet for each availability zone.
Original: * The `clusterNetwork` and `serviceNetwork` network configurations in the seed cluster persist to the deployed cluster. The Lifecycle Agent embeds these settings in the seed image and they cannot be changed later in the image-based installation and deployment process.
Revised: * The `clusterNetwork` and `serviceNetwork` network configurations in the seed cluster persist to the deployed cluster. The Lifecycle Agent embeds these settings in the seed image. You cannot change these settings later in the image-based installation and deployment process.
Original: The role assignment mechanism within `platform.aws.vpc.subnets` (e.g., specifying types like `IngressControllerLB`, `ClusterNode`, `ControlPlaneExternalLB`, `ControlPlaneInternalLB`, `BootstrapNode`) is the comprehensive way the OpenShift installer identifies suitable subnets for various cluster services and components.
Revised: The role assignment mechanism within `platform.aws.vpc.subnets`, such as specifying types like `IngressControllerLB`, `ClusterNode`, `ControlPlaneExternalLB`, `ControlPlaneInternalLB`, `BootstrapNode` is the comprehensive way the OpenShift installer identifies suitable subnets for various cluster services and components.
Original: You can control the network placement of OpenShift Load Balancers on AWS, including those for the Ingress Controller, by explicitly defining your VPC's subnets and assigning them specific roles directly within the `platform.aws.vpc.subnets` section of the `install-config.yaml` file. This method provides granular control over which subnets are used for resources like the Ingress Controller and other cluster components.
Revised: You can control the network placement of OpenShift Load Balancers on AWS, including those for the Ingress Controller, by explicitly defining your virtual private cloud's (VPC's) subnets and assigning them specific roles directly within the `platform.aws.vpc.subnets` section of the `install-config.yaml` file. This method provides granular control over which subnets are used for resources, such as the Ingress Controller and other cluster components.
Original: You can manage application traffic efficiently by allocating load balancers. Network administrations can allocate load balancers to customize deployments to ensures optimal traffic distribution, high availability of applications, uninterupted service, and network segmentation.
Revised: You can manage application traffic efficiently by allocating load balancers. Network administrators can allocate load balancers to customize deployments which can ensure optimal traffic distribution, high availability of applications, uninterrupted service, and network segmentation.
Original: The MTU value of the OVN overlay networking in {microshift-short} must be 100 bytes smaller than the MTU value of the base network. If no MTU value is configured, {microshift-short} autoconfigures the value using the MTU value of the default gateway (IPV4 or V6) of the host. If the auto-configuration does not work correctly, the MTU value can be configured manually. For example, if the MTU value of the network is `9000`, the OVN MTU size must be set to `8900`.
Revised: The MTU value of the OVN overlay networking in {microshift-short} must be 100 bytes smaller than the MTU value of the base network. If no MTU value is configured, {microshift-short} autoconfigures the value using the MTU value of the default gateway (IPv4 or IPv6) of the host. If the auto-configuration does not work correctly, the MTU value can be configured manually. For example, if the MTU value of the network is `9000`, the OVN MTU size must be set to `8900`.
Original: The MTU value of the OVN overlay networking in {microshift-short} must be 100 bytes smaller than the MTU value of the base network. If no MTU value is configured, {microshift-short} autoconfigures the value using the MTU value of the default gateway (Internet Protocol version 4 (IPv4) or Internet Protocol version 6 (IPv6)) of the host. If the auto-configuration does not work correctly, the MTU value can be configured manually. For example, if the MTU value of the network is `9000`, the OVN MTU size must be set to `8900`.
Revised: The MTU value of the OVN overlay networking in {microshift-short} must be 100 bytes smaller than the MTU value of the base network. If no MTU value is configured, {microshift-short} autoconfigures the value using the MTU value of the default gateway (IPv4 or IPv6) of the host. If the auto-configuration does not work correctly, the MTU value can be configured manually. For example, if the MTU value of the network is `9000`, the OVN MTU size must be set to `8900`.
Original: Volume Attribute Classes have parameters that describe volumes belonging to them. Different parameters can be accepted depending on the provisioner or the resizer. If a parameter is omitted, the default is used at volume provisioning. If a user applies the PVC with a different Volume Attributes Class with omitted parameters, the default value of the parameters might be used depending on the CSI driver implementation. For more information, see the related CSI driver documentation.
Revised: Volume Attributes Classes have parameters that describe volumes belonging to them. Different parameters can be accepted depending on the provisioner or the resizer. If a parameter is omitted, the default is used at volume provisioning. If you apply the PVC with a different Volume Attributes Class with omitted parameters, the default value of the parameters might be used depending on the CSI driver implementation. For more information, see the related CSI driver documentation.
Original: 
[IMPORTANT]
You can only use egress lockdown on clusters that use the following AWS regions:

* `us-west-2`
* `us-east-1`
* `us-east-2`
* `ap-northeast-1`
* `ap-northeast-2`
* `ap-northeast-3`
* `ap-south-1`
* `ap-southeast-1`
* `ap-southeast-2`
* `ca-central-1`
* `eu-central-1`
* `eu-north-1`
* `eu-west-1`
* `eu-west-2`
* `eu-west-3`
* `sa-east-1`
All public and private clusters with egress lockdown get their Red Hat container images from a registery that is located in the local region of the cluster instead of gathering these images from various endpoints and registeries on the Internet. You can create a fully operational cluster that does not require a public egress by configuring a virtual private cloud (VPC) and using the `--properties zero_egress:true` flag when creating your cluster.
Revised: Other terms are sometimes used to refer to a specific level of internet connectivity, and these environments might require additional unique configurations. These network types differ from a "Standard Network", which has full access to the Internet.
Original: 
[IMPORTANT]
You can only use egress lockdown on clusters that use the following AWS regions:

* `us-west-2`
* `us-east-1`
* `us-east-2`
* `ap-northeast-1`
* `ap-northeast-2`
* `ap-northeast-3`
* `ap-south-1`
* `ap-southeast-1`
* `ap-southeast-2`
* `ca-central-1`
* `eu-central-1`
* `eu-north-1`
* `eu-west-1`
* `eu-west-2`
* `eu-west-3`
* `sa-east-1`
All public and private clusters with egress lockdown get their Red Hat container images from a registery that is located in the local region of the cluster instead of gathering these images from various endpoints and registeries on the Internet. You can create a fully operational cluster that does not require a public egress by configuring a virtual private cloud (VPC) and using the `--properties zero_egress:true` flag when creating your cluster.
:FeatureName: Egress lockdown
include::snippets/technology-preview.adoc[]
Revised: This isolation depends on a physical separation, or an "air gap", between machines on the internal network and any part of an external network.
Original: 
[IMPORTANT]
You can only use egress lockdown on clusters that use the following AWS regions:

* `us-west-2`
* `us-east-1`
* `us-east-2`
* `ap-northeast-1`
* `ap-northeast-2`
* `ap-northeast-3`
* `ap-south-1`
* `ap-southeast-1`
* `ap-southeast-2`
* `ca-central-1`
* `eu-central-1`
* `eu-north-1`
* `eu-west-1`
* `eu-west-2`
* `eu-west-3`
* `sa-east-1`
All public and private clusters with egress lockdown get their Red Hat container images from a registery that is located in the local region of the cluster instead of gathering these images from various endpoints and registeries on the Internet. You can create a fully operational cluster that does not require a public egress by configuring a virtual private cloud (VPC) and using the `--properties zero_egress:true` flag when creating your cluster.
:FeatureName: Egress lockdown
include::snippets/technology-preview.adoc[]
Revised: |Restricted network
Original: 
[IMPORTANT]
You can only use egress lockdown on clusters that use the following AWS regions:

* `us-west-2`
* `us-east-1`
* `us-east-2`
* `ap-northeast-1`
* `ap-northeast-2`
* `ap-northeast-3`
* `ap-south-1`
* `ap-southeast-1`
* `ap-southeast-2`
* `ca-central-1`
* `eu-central-1`
* `eu-north-1`
* `eu-west-1`
* `eu-west-2`
* `eu-west-3`
* `sa-east-1`
All public and private clusters with egress lockdown get their Red Hat container images from a registery that is located in the local region of the cluster instead of gathering these images from various endpoints and registeries on the Internet. You can create a fully operational cluster that does not require a public egress by configuring a virtual private cloud (VPC) and using the `--properties zero_egress:true` flag when creating your cluster.
:FeatureName: Egress lockdown
include::snippets/technology-preview.adoc[]
Revised: A physical connection may exist between machines on the internal network and an external network, but network traffic is limited by additional configurations, such as firewalls and proxies.
Original: Before you can use your VPC to create a {hcp-title} cluster, you must tag your VPC subnets. Automated service preflight checks verify that these resources are tagged correctly before you can use these resources. The following table shows how your resources should be tagged:
Revised: Before you can use your VPC to create a {hcp-title} cluster, you must tag your VPC subnets. Automated service preflight checks verify that these resources are tagged correctly. The following table shows how your resources should be tagged:
Original: The Terraform instructions are for testing and demonstration purposes. Your own installation requires some modifications to the VPC for your own use. You should also ensure that when you use this Terraform script it is in the same region that you intend to install your cluster. In these examples, use `us-east-2`.
Revised: The Terraform instructions are for testing and demonstration purposes. Your own installation requires some modifications to the VPC for your own use. You should also ensure that when you use this Terraform script it is in the same region that you intend to install your cluster. These examples use `us-east-2`.
Original: 
[IMPORTANT]
Revised: All public and private clusters with egress lockdown get their Red{nbsp}Hat container images from an Amazon Elastic Container Registry (ECR) located in the local region of the cluster instead of gathering these images from various endpoints and registries on the internet. ECR provides storage for OpenShift release images as well as Red{nbsp}Hat Operators. All requests for ECR are kept within your AWS network by serving them over a VPC endpoint within your cluster.
Original: 
[IMPORTANT]
You can only use egress lockdown on clusters that use the following AWS regions:

* `us-west-2`
* `us-east-1`
* `us-east-2`
* `ap-northeast-1`
* `ap-northeast-2`
* `ap-northeast-3`
* `ap-south-1`
* `ap-southeast-1`
* `ap-southeast-2`
* `ca-central-1`
* `eu-central-1`
* `eu-north-1`
* `eu-west-1`
* `eu-west-2`
* `eu-west-3`
* `sa-east-1`
All public and private clusters with egress lockdown get their Red Hat container images from a registery that is located in the local region of the cluster instead of gathering these images from various endpoints and registeries on the Internet. You can create a fully operational cluster that does not require a public egress by configuring a virtual private cloud (VPC) and using the `--properties zero_egress:true` flag when creating your cluster.
Revised: Other terms are sometimes used to refer to a specific level of internet connectivity, and these environments might require additional unique configurations. These network types differ from a "standard network", which has full access to the internet.
Original: 
[IMPORTANT]
You can only use egress lockdown on clusters that use the following AWS regions:

* `us-west-2`
* `us-east-1`
* `us-east-2`
* `ap-northeast-1`
* `ap-northeast-2`
* `ap-northeast-3`
* `ap-south-1`
* `ap-southeast-1`
* `ap-southeast-2`
* `ca-central-1`
* `eu-central-1`
* `eu-north-1`
* `eu-west-1`
* `eu-west-2`
* `eu-west-3`
* `sa-east-1`
All public and private clusters with egress lockdown get their Red Hat container images from a registery that is located in the local region of the cluster instead of gathering these images from various endpoints and registeries on the Internet. You can create a fully operational cluster that does not require a public egress by configuring a virtual private cloud (VPC) and using the `--properties zero_egress:true` flag when creating your cluster.
Revised: == Glossary of network environment terms
Original: The Terraform instructions are for testing and demonstration purposes. Your own installation requires some modifications to the VPC for your own use. You should also ensure that when you use this Terraform script it is in the same region that you intend to install your cluster. These examples use `us-east-2`.
Revised: The Terraform instructions are for testing and demonstration purposes. Your own installation requires some modifications to the VPC for your own use. You should also ensure that when you use this Terraform script, it is in the same region that you intend to install your cluster. These examples use `us-east-2`.