gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: <1> The `name` value in the `BackupStorageLocation` resource must follow the `<DataProtectionApplication.metadata.name>-<index>` pattern. The `<index>` represents the position of the corresponding `backupLocation` entry in the `spec.backupLocations` field in the `DataProtectionApplication` resource. The position starts from `1`. If the `metadata.name` value of the `DataProtectionApplication` resource is changed in the `OadpDataProtectionApplication.yaml` file, update the `metadata.name` field in the `BackupStorageLocation` resource accordingly.
Revised: <1> The `name` value in the `BackupStorageLocation` resource must follow the `<DataProtectionApplication.metadata.name>-<index>` pattern. The `<index>` represents the position of the corresponding `backupLocations` entry in the `spec.backupLocations` field in the `DataProtectionApplication` resource. The position starts from `1`. If the `metadata.name` value of the `DataProtectionApplication` resource is changed in the `OadpDataProtectionApplication.yaml` file, update the `metadata.name` field in the `BackupStorageLocation` resource accordingly.
Original: bucket: <your_bucket_name> <3>
prefix: <cluster_name> <3>
<2> Specify the URL for your S3-compatible bucket.
<3> The `bucket` defines the bucket name that is created in S3 backend. The `prefix` defines the name of the subdirectory that will be automatically created in the `bucket`. The combination of `bucket` and `prefix` must be unique for each target cluster to avoid interference between them. To ensure a unique storage directory for each target cluster, you can use the {rh-rhacm} hub template function, for example, `prefix: {{hub .ManagedClusterName hub}}`.
Revised: <2> If more than one location is specified under `backupLocations` in the `OadpDataProtectionApplication` CR, ensure that each location has a corresponding `OadpBackupStorageLocation` CR added for status tracking. Ensure that the name of each additional `OadpBackupStorageLocation` CR is overridden with the correct index as described in the example `OadpBackupStorageLocationStatus.yaml` file.
Original: bucket: <your_bucket_name> <3>
prefix: <cluster_name> <3>
<2> Specify the URL for your S3-compatible bucket.
<3> The `bucket` defines the bucket name that is created in S3 backend. The `prefix` defines the name of the subdirectory that will be automatically created in the `bucket`. The combination of `bucket` and `prefix` must be unique for each target cluster to avoid interference between them. To ensure a unique storage directory for each target cluster, you can use the {rh-rhacm} hub template function, for example, `prefix: {{hub .ManagedClusterName hub}}`.
Revised: <4> The `bucket` defines the bucket name that is created in the S3 backend. The `prefix` defines the name of the subdirectory that gets automatically created in the `bucket`. The combination of `bucket` and `prefix` must be unique for each target cluster to avoid interference between them. To ensure a unique storage directory for each target cluster, you can use the {rh-rhacm} hub template function, for example, `prefix: {{hub .ManagedClusterName hub}}`.
Original: bucket: <your_bucket_name> <3>
prefix: <cluster_name> <3>
<2> Specify the URL for your S3-compatible bucket.
<3> The `bucket` defines the bucket name that is created in S3 backend. The `prefix` defines the name of the subdirectory that will be automatically created in the `bucket`. The combination of `bucket` and `prefix` must be unique for each target cluster to avoid interference between them. To ensure a unique storage directory for each target cluster, you can use the {rh-rhacm} hub template function, for example, `prefix: {{hub .ManagedClusterName hub}}`.
Revised: <4> The `bucket` value defines the bucket name that is created in S3 backend. The `prefix` value defines the name of the subdirectory that will be automatically created in the `bucket`. The combination of `bucket` and `prefix` values must be unique for each target cluster to avoid interference between them. To ensure a unique storage directory for each target cluster, you can use the {rh-rhacm-title} hub template function, for example, `prefix: {{hub .ManagedClusterName hub}}`.
Original: Cloud, VM, and bare metal CPU performance can be capable of handling much more than one Gbps network throughput. When using higher bandwidth links such as 10 or 40 Gbps, reduced performance can occur. This is a known issue in Geneve-based environments and is not specific to containers or {product-title}. Any network that relies on Geneve or VXLAN tunnels will perform similarly because of the tunnel implementation.
If you are looking to push beyond one Gbps, you can:
Revised: For environments where maximum throughput and CPU efficiency are critical, you can further optimize performance and make full use of the NIC's capabilities with the following strategies:
Original: Geneve encapsulates all tunneled traffic in user datagram protocol (UDP) packets. However, this leads to increased CPU utilization. Both these outer- and inner-packets are subject to normal checksumming rules to guarantee data is not corrupted during transit. Depending on CPU performance, this additional processing overhead can cause a reduction in throughput and increased latency when compared to traditional, non-overlay networks.
Revised: Cloud, virtual, and bare-metal environments running {product-title} can use a high percentage of a NIC's capabilities with minimal tuning. Production clusters using OVN-Kubernetes with Geneve tunneling can handle high-throughput traffic effectively and scale up (for example, utilizing 100 Gbps NICs) and scale out (for example, adding more NICs) without requiring special configuration.
Original: Geneve encapsulates all tunneled traffic in user datagram protocol (UDP) packets. However, this leads to increased CPU utilization. Both these outer- and inner-packets are subject to normal checksumming rules to guarantee data is not corrupted during transit. Depending on CPU performance, this additional processing overhead can cause a reduction in throughput and increased latency when compared to traditional, non-overlay networks.
Cloud, VM, and bare metal CPU performance can be capable of handling much more than one Gbps network throughput. When using higher bandwidth links such as 10 or 40 Gbps, reduced performance can occur. This is a known issue in Geneve-based environments and is not specific to containers or {product-title}. Any network that relies on Geneve or VXLAN tunnels will perform similarly because of the tunnel implementation.
If you are looking to push beyond one Gbps, you can:
* Evaluate network plugins that implement different routing techniques, such as border gateway protocol (BGP).
* Use Geneve-offload capable network adapters. Geneve-offload moves the packet checksum calculation and associated CPU overhead off of the system CPU and onto dedicated hardware on the network adapter. This frees up CPU cycles for use by pods and applications, and allows users to utilize the full bandwidth of their network infrastructure.
Geneve-offload does not reduce latency. However, CPU utilization is reduced even in latency tests.
Revised: * Use Geneve-offload capable network adapters. Geneve-offload moves the packet checksum calculation and associated CPU overhead off of the system CPU and onto dedicated hardware on the network adapter. This frees up CPU cycles for use by pods and applications, and allows users to use the full bandwidth of their network infrastructure.
Original: With this release, the {microshift-short} multiple networking plug-in is included in the {microshift-short} RPM. To deploy the Multus container network interface (CNI), you can either set the value in the {microshift-short} configuration file, or install the `microshift-multus` RPM, which contains a configuration snippet. For more information, see xref:../microshift_networking/microshift_multiple_networks/microshift-cni-multus.adoc#microshift-cni-multus[About using multiple networks].
Revised: With this release, the {microshift-short} RPM includes the {microshift-short} multiple networking plug-in. To deploy the Multus container network interface (CNI), you can either set the value in the {microshift-short} configuration file, or install the `microshift-multus` RPM, which contains a configuration snippet. For more information, see xref:../microshift_networking/microshift_multiple_networks/microshift-cni-multus.adoc#microshift-cni-multus[About using multiple networks].
Original: With this release, the {microshift-short} multiple networking plug-in is included in the {microshift-short} RPM. To deploy the Multus container network interface (CNI), you can either set the value in the {microshift-short} configuration file, or install the `microshift-multus` RPM, which contains a configuration snippet. For more information, see xref:../microshift_networking/microshift_multiple_networks/microshift-cni-multus.adoc#microshift-cni-multus[About using multiple networks].
Revised: With this release, the {microshift-short} multiple networking plug-in ships with the {microshift-short} RPM. To deploy the Multus container network interface (CNI), you can either set the value in the {microshift-short} configuration file, or install the `microshift-multus` RPM, which contains a configuration snippet. For more information, see xref:../microshift_networking/microshift_multiple_networks/microshift-cni-multus.adoc#microshift-cni-multus[About using multiple networks].
Original: During the update process, nodes in the cluster might become temporarily unavailable. In the case of worker nodes, the machine health check might identify such nodes as unhealthy and reboot them. To avoid rebooting such nodes, pause all the `MachineHealthCheck` resources before updating the cluster.
Revised: During the update process, nodes in the cluster might become temporarily unavailable. In the case of worker nodes, the `MachineHealthCheck` resources might identify such nodes as unhealthy and reboot them. To avoid rebooting such nodes, pause all the `MachineHealthCheck` resources before updating the cluster.
Original: During the update process, nodes in the cluster might become temporarily unavailable. In the case of worker nodes, the machine health check might identify such nodes as unhealthy and reboot them. To avoid rebooting such nodes, pause all the `MachineHealthCheck` resources before updating the cluster.
Revised: Some `MachineHealthCheck` resources might not need to be paused. If your `MachineHealthCheck` resource relies on unrecoverable conditions, pausing that MHC is unnecessary.
Original: Use this procedure to install the {microshift-short} Multus CNI plugin alongside a new {microshift-short} installation. The {microshift-short} Multus Container Network Interface (CNI) plugin is not installed by default. If you want to attach additional networks to a pod for high-performance network configurations, install the `microshift-multus` RPM package.
Revised: You can install the {microshift-short} Multus Container Network Interface (CNI) plugin alongside a new {microshift-short} installation. If you want to attach additional networks to a pod for high-performance network configurations, install the `microshift-multus` RPM package.
Original: //[id="microshift-4-19-example-ra-feature_{context}"]
//==== Example RA feature here
Revised: With this release, you can use the `microshift healthcheck` command with various options to run a basic health check on your applications. For more information, see xref:../microshift_running_apps/microshift-greenboot-workload-scripts.adoc#microshift-greenboot-workload-scripts_microshift-greenboot-workload-scripts[Greenboot workload health check scripts].
Original: * Previously, incorrect addresses were being passed to the Kubernetes EndpointSlice on a cluster, and this issue prevented the installation of the MetalLB Operator on an Agent-based cluster in an IPv6 disconnected environment. With this release, a fix modifies the address evaluation method. Red{nbsp}Hat Marketplace pods can now successfully connect to the cluster API server so that the installation of MetalLB Operator and handling of ingress traffic in IPv6 disconnected environments can occur. (link:https://issues.redhat.com/browse/OCPBUGS-53314[*OCPBUGS-53314*])
Revised: * Previously, incorrect addresses were being passed to the Kubernetes EndpointSlice on a cluster. This issue prevented the installation of the MetalLB Operator on an Agent-based cluster in an IPv6 disconnected environment. With this release, a fix modified the address evaluation method. Red{nbsp}Hat Marketplace pods can now successfully connect to the cluster API server so that the installation of MetalLB Operator and handling of ingress traffic in IPv6 disconnected environments can occur. (link:https://issues.redhat.com/browse/OCPBUGS-53314[*OCPBUGS-53314*])
Original: * Previously, a code migration operation failed to process external labels correctly on the *Home > Overview > Status* pane on the *Administrator perspective* of the web console. These external labels are required to prevent silenced alert notifications from getting added to *Status* pane. Because the *Status* pane did not handle external labels correctly, the pane provided links to *Alert detail* pages but generated a "no matching alerts found" message when you clicked on a link. With this release, the *Status* pane accepts external labels so clicking on an alert links to the correct *Alert detail* page. (link:https://issues.redhat.com/browse/OCPBUGS-51118[*OCPBUGS-51118*])
Revised: * Previously, a code migration operation failed to process external labels correctly on the *Home* -> *Overview* -> *Status* pane on the *Administrator perspective* of the web console. These external labels are required to prevent silenced alert notifications from getting added to *Status* pane. Because the *Status* pane did not handle external labels correctly, the pane provided links to *Alert detail* pages but generated a "no matching alerts found" message when you clicked on a link. With this release, the *Status* pane accepts external labels so clicking on an alert links to the correct *Alert detail* page. (link:https://issues.redhat.com/browse/OCPBUGS-51118[*OCPBUGS-51118*])
Original: * In order to attempt a live storage migration, the `liveMigrate` field in the migration plan specification must be set to true, and `KubeVirt` must be configred and be enabled to perform live storage migration.
Revised: * To attempt a live storage migration, the `liveMigrate` field in the migration plan specification must be set to true, and `KubeVirt` must be configured, and be enabled to perform live storage migration.
Original: * Previously, the **Observe** menu of the administrator perspective could have been duplicated depending of the installed {ocp-product-title} version. Now, the **Observe** menu appears only once. (link:https://issues.redhat.com/browse/NETOBSERV-2139 [*NETOBSERV-2139*])
Revised: * Previously, the **Observe** menu of the administrator perspective could have been duplicated depending on the installed {ocp-product-title} version. Now, the **Observe** menu appears only once. (link:https://issues.redhat.com/browse/NETOBSERV-2139 [*NETOBSERV-2139*])
Original: * With the upcoming version of {product-title} 4.19+, the **Observe** menu in the administrator perspective might be duplicated depending on the installed {product-title} version. This fix ensures that the **Observe** menu appears only once in future versions of OpenShift. (link:https://issues.redhat.com/browse/NETOBSERV-2139[NETOBSERV-2139])
Revised: * This fix ensures that the *Observe* menu appears only once in future versions of {product-title}. (link:https://issues.redhat.com/browse/NETOBSERV-2139[*NETOBSERV-2139*])
Original: * This fix ensures that the *Observe* menu appears only once in future versions of {ocp-title}. (link:https://issues.redhat.com/browse/NETOBSERV-2139[*NETOBSERV-2139*])
Revised: * This fix ensures that the *Observe* menu appears only once in future versions of {product-title}. (link:https://issues.redhat.com/browse/NETOBSERV-2139[*NETOBSERV-2139*])
Original: The workload or application health check script described in this tutorial uses the {microshift-short} health check functions that are available in the `/usr/share/microshift/functions/greenboot.sh` file. This enables you to reuse procedures already implemented for the {microshift-short} core services.
The health check performs the following actions:
* Gets a wait timeout of the current boot cycle for the `wait_for` function.
* Calls the `namespace_images_downloaded` function to wait until pod images are available.
* Calls the `namespace_pods_ready` function to wait until pods are ready.
* Calls the `namespace_pods_not_restarting` function to verify pods are not restarting.
Revised: * `--daemonsets`
Original: $ microshift healthcheck --custom '{"openshift-storage":{"deployments": ["lvms-operator"], "daemonsets": ["vg-manager"]}, "openshift-ovn-kubernetes":{"daemonsets": ["ovnkube-master", "ovnkube-node"]}}'
Revised: $ sudo microshift healthcheck --custom '{"openshift-storage":{"deployments": ["lvms-operator"], "daemonsets": ["vg-manager"]}, "openshift-ovn-kubernetes":{"daemonsets": ["ovnkube-master", "ovnkube-node"]}}'

# microshift healthcheck --custom '{"openshift-storage":{"deployments": ["lvms-operator"], "daemonsets": ["vg-manager"]}, "openshift-ovn-kubernetes":{"daemonsets": ["ovnkube-master", "ovnkube-node"]}}'
Original: //* microshift_running_apps/microshift-greenboot-workload-scripts.adoc
Health check scripts are available in `/usr/lib/greenboot/check`, a read-only directory in RPM-OSTree systems. The following health checks are included with the `greenboot-default-health-checks` framework.
Revised: Health check scripts are available in `/usr/lib/greenboot/check`, a read-only directory in RHEL For Edge and RHEL Image Mode systems. The following health checks are included with the `greenboot-default-health-checks` framework.
Original: . Optional: If you want to modify a parameter, you can specify `--param Param1=Value1`, `--param Param2=Value2`, and so on. For example, if you wanted to modify the region, name, AZ count, and VPC's CIDR parameters, you could run:
Revised: . Optional: If you want to modify a parameter, you can specify the parameter using optional argument flags such as `--param Param1=Value1` and `--param Param2=Value2`. For example, if you want to modify the region, name, availability zone (AZ) count, and VPC's CIDR parameters, you could run:
Original: The `rosa create network` command is available in v.1.2.48 or later of the ROSA CLI. This command uses AWS CloudFormation to create a VPC and other networking components used to install a ROSA cluster. CloudFormation is a native AWS infrastructure-as-code tool, compatible with the AWS CLI. For more information on AWS CloudFormation, see the additional resources.
Revised: The `rosa create network` command is available in v.1.2.48 or later of the ROSA command-line interface (CLI). The command uses AWS CloudFormation to create a VPC and the other networking components used to install a ROSA cluster. CloudFormation is a native AWS infrastructure-as-code tool and is compatible with the AWS CLI. For more information on AWS CloudFormation, see the additional resources.
Original: The command takes about 5 minutes to run, providing regular status updates from AWS as resources are created. If there is an issue with CloudFormation, a rollback will be attempted. If any other issues 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, follow the error message instructions or contact AWS support.
Original: Save the subnet IDs that are created as a result of this command since these subnets are needed when creating the cluster. Replace `$SUBNET_IDS` in the `rosa cluster create` command below with these values in a comma-separated list.
Revised: Save the subnet IDs that are created as a result of this command since these subnet IDs are needed to create the cluster. Replace `$SUBNET_IDS` in the `rosa cluster create` command below with these values in a comma-separated list.
Original: You can use a custom CloudFormation template by specifying a new directory with `--template-dir`, and then specifying a template name when you use `rosa create network`. You can also simply use the aws cloudformations command directly when using custom CloudFormation templates.
Revised: You can use a custom CloudFormation template by specifying a new directory with `--template-dir` and then specifying a template name when you use `rosa create network`. You can also use the AWS CloudFormations command directly when using custom CloudFormation templates.
Original: As with any VPC used for ROSA, the VPC created by this method is not managed by ROSA, and ROSA is not aware of its dependency on this VPC. If you manipulate the VPC while a ROSA cluster is running within it, you could introduce risk to the cluster.
Revised: As with any ROSA VPC, the VPC is not managed by ROSA and ROSA is not aware of its dependency on this VPC. If you manipulate the VPC while a ROSA cluster is running within it, you could introduce risk to the cluster.
Original: == Creating a Virtual Private Cloud for your egress lockdown {hcp-title} clusters
You must have a Virtual Private Cloud (VPC) to create {hcp-title} clusters. You can use one of the following methods to create a VPC:
The Terraform instructions are for testing and demonstration purposes. Your own installation requires modifications to the VPC for your specific needs and constraints. You should also ensure that when you use the following Terraform script it is in the same region that you intend to install your cluster.
include::modules/rosa-hcp-vpc-terraform.adoc[leveloffset=+2]
* See the link:https://github.com/openshift-cs/terraform-vpc-example/tree/main/zero-egress[Zero Egress Terraform VPC Example] repository for a detailed list of all options available when customizing the VPC for your needs.
Revised: * See the link:https://github.com/openshift-cs/terraform-vpc-example[Terraform VPC] repository for a detailed list of all options available when customizing the VPC to your needs.
Original: == Creating a Virtual Private Cloud for your egress lockdown {hcp-title} clusters
You must have a Virtual Private Cloud (VPC) to create {hcp-title} clusters. You can use one of the following methods to create a VPC:
The Terraform instructions are for testing and demonstration purposes. Your own installation requires modifications to the VPC for your specific needs and constraints. You should also ensure that when you use the following Terraform script it is in the same region that you intend to install your cluster.
include::modules/rosa-hcp-vpc-terraform.adoc[leveloffset=+2]
* See the link:https://github.com/openshift-cs/terraform-vpc-example/tree/main/zero-egress[Zero Egress Terraform VPC Example] repository for a detailed list of all options available when customizing the VPC for your needs.
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: include::modules/rosa-hcp-vpc-terraform.adoc[leveloffset=1]
[id="additional-resources_rosa-hcp-quickstart-vpc-terraform"]
Revised: * See the link:https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-ec2-vpc.html[AWS CloudFormation documentation] for more information about structuring CloudFormation files to create VPCs.
Original: include::modules/rosa-hcp-vpc-terraform.adoc[leveloffset=1]
[id="additional-resources_rosa-hcp-quickstart-vpc-terraform"]
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.