gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: * The `Istio` resource replaces the `ServiceMeshControlPlane` resource.
* The `IstioCNI` resource manages the Istio Container Network Interface (CNI).
Revised: {SMProduct} 3 simplifies versioning. The Operator manages only the `{istio}` resource, which is only responsible for {istio} and does not manage Kiali or other components. This means the `{istio}` resource only needs to specify the {istio} component version. Each release of {SMProduct} provides support for the latest available release of {istio} per Operator version. For example, {SMProduct} 3.0.0 supports {istio} 1.24.0. While additional {istio} versions might be available in the Operator to assist with upgrades, product support including patches for Common Vulnerabilities and Exposures (CVEs) are only provided for the latest {istio} version for a given Operator release. Thus, users are expected to update to the latest available version of {istio} for their given Operator release.
Original: * The `Istio` resource replaces the `ServiceMeshControlPlane` resource.
* The `IstioCNI` resource manages the Istio Container Network Interface (CNI).
Revised: In {SMProduct} 2, the `ServiceMeshControlPlane` resource managed multiple operands, including {istio}, Kiali, and Jaeger. Each component maintained its own version containing the following three levels of versioning:
Original: * The `Istio` resource replaces the `ServiceMeshControlPlane` resource.
* The `IstioCNI` resource manages the Istio Container Network Interface (CNI).
Revised: Each {SMProduct} release supports the latest available {istio} version for that Operator version. For example, {SMProduct} 3.0.0 supports {istio} 1.24.0. While the Operator might contain other {istio} versions to support upgrades, product support, including patches for Common Vulnerabilities and Exposures (CVEs), covers only the latest {istio} version in a given Operator release. For each Operator release, update to the most recent {istio} version available.
Original: * `Istio` resource
{SMProduct} 2 uses a resource called `ServiceMeshControlPlane` to configure Istio. In {SMProduct} 3, the `ServiceMeshControlPlane` resource is replaced with a resource called `Istio`.
The `Istio` resource contains a `spec.values` field that derives its schema from Istio's Helm chart values. This means that configuration examples from the community Istio documentation can often be applied directly to the {SMProduct} 3 `Istio` resource.
The `Istio` resource provides an additional validation schema enabling the ability to explore the resource running the following the {ocp-short-name} command line interface (CLI) command:
Revised: You can view an additional validation schema of the `{istio}` resource by running the following command:
Original: * `Istio` resource
{SMProduct} 2 uses a resource called `ServiceMeshControlPlane` to configure Istio. In {SMProduct} 3, the `ServiceMeshControlPlane` resource is replaced with a resource called `Istio`.
The `Istio` resource contains a `spec.values` field that derives its schema from Istio's Helm chart values. This means that configuration examples from the community Istio documentation can often be applied directly to the {SMProduct} 3 `Istio` resource.
The `Istio` resource provides an additional validation schema enabling the ability to explore the resource running the following the {ocp-short-name} command line interface (CLI) command:
//Note that there might be an attribute for OpenShift CLI. Check main _attributes file, and if there is an attribute for it, add it to list for service-mesh-docs-main _attributes file.
The Istio Container Network Interface (CNI) node agent is used to configure traffic redirection for pods in the mesh. It runs as a daemon set, on every node, with elevated privileges.
In {SMProduct} 2, the Operator deployed an Istio CNI instance for each minor version of Istio present in the cluster, and pods were automatically annotated during sidecar injection so they picked up the correct Istio CNI. While this meant that the management of Istio CNI was mostly hidden from you, it obscured the fact that the Istio CNI agent has an independent lifecycle from the Istio control plane and, in some cases, the Istio CNI agent must be be upgraded separately.
Revised: In {SMProduct} 2, the Operator deployed an {istio} CNI instance for each minor version of {istio} present in the cluster, and pods were automatically annotated during sidecar injection so they picked up the correct {istio} CNI. The {istio} CNI agent has an independent lifecycle from the {istio} control plane and, in some cases, you must upgrade the {istio} CNI agent separately.
Original: Converting resources provides an opportunity to verify that migrating Machine API resources to the Cluster API works as expected before deciding to use the Cluster API in production clusters.
After converting a Machine API resource to an equivalent Cluster API resource, you can examine the new resource to verify that the features and configuration match the original Machine API resource.
Revised: Migrating arbitrary Machine API resources to Cluster API provides an opportunity to verify that things work as expected before deciding to use the Cluster API in production clusters.
After migrating a Machine API resource to an equivalent Cluster API resource, you can examine the new resource to verify that the features and configuration match the original Machine API resource.
Original: On clusters that support converting between Machine API and Cluster API resources, the two-way synchronization controller supports converting a Cluster API resource to a Machine API resource.

You can convert resources that you originally converted from the Machine API to the Cluster API, or resources that you created as Cluster API resources initially.
Converting an original Machine API resource to a Cluster API resource and then converting it back provides an opportunity to verify that the migration process works as expected.
Revised: On clusters that support migrating between Machine API and Cluster API resources, the two-way synchronization controller supports converting a Cluster API resource to a Machine API resource.

You can then migrate resources that you originally migrated from the Machine API to the Cluster API, or resources that you created as Cluster API resources initially.
Migrating an original Machine API resource to a Cluster API resource and then migrating it back provides an opportunity to verify that the process works as expected.
Original: <5> The unconverted value for a {from-api-name} resource.
Do not change the value in this part of the specification.
Revised: <5> The current authority for the {from-api-name} resource. And indicates which system is currently managing the resource.
Do not change the value in this part of the specification.
The value will be set to `Migrating` when the authority for the resource is actively being transferred between one compute system and the other. If the field stays in this value for a while it means the migration is experiencing an issue (check logs/events ?).
Original: Converting resources provides an opportunity to verify that migrating Machine API resources to the Cluster API works as expected before deciding to use the Cluster API in production clusters.
After converting a Machine API resource to an equivalent Cluster API resource, you can examine the new resource to verify that the features and configuration match the original Machine API resource.
Revised: By migrating a Machine API resource to use the Cluster API, you can verify that everything works as expected before deciding to use the Cluster API in production clusters.
After migrating a Machine API resource to an equivalent Cluster API resource, you can examine the new resource to verify that the features and configuration match the original Machine API resource.
Original: Install modes are a multi-tenancy feature of {olmv0-first}. {olmv1} does no support multi-tenancy and assumes cluster extensions are scoped to the cluster by default. However, some existing Operators do not support the `AllNamespaces` install mode. You can deploy an extension in a specific namespace by using the `OwnNamespace` or `SingleNamespace` install modes as a Technology Preview feature for `registry+v1` bundles.
Revised: Install modes are a multi-tenancy feature of {olmv0-first}. {olmv1} does no support multi-tenancy and assumes cluster extensions are scoped to the cluster by default (`AllNamespaces` install mode in {olmv0-first}). However, some existing Operators do not support the `AllNamespaces` install mode. You can deploy an extension in a specific namespace by using the `OwnNamespace` or `SingleNamespace` install modes as a Technology Preview feature for `registry+v1` bundles. The extension will still only be able to be installed _once_ on the cluster.
Original: * In {product-title} {product-version}, {aws-first} clusters with more than 250 nodes that use IPSEC for network encryption might experience intermittent loss of pod-to-pod connectivity. This prevents some pods on certain nodes from reaching services on other nodes, resulting in connection timeouts.
Revised: * In the {product-title} {product-version}, {aws-first} clusters with more than 250 nodes that use IPSEC for network encryption might experience intermittent loss of pod-to-pod connectivity. This prevents some pods on certain nodes from reaching services on other nodes, resulting in connection timeouts.
Original: * In {product-title} {product-version}, {aws-first} clusters with more than 250 nodes that use IPSEC for network encryption might experience intermittent loss of pod-to-pod connectivity. This prevents some pods on certain nodes from reaching services on other nodes, resulting in connection timeouts.
Revised: * In {product-title} {product-version} and {aws-first}, clusters with more than 250 nodes that use IPSEC for network encryption might experience intermittent loss of pod-to-pod connectivity. This prevents some pods on certain nodes from reaching services on other nodes, resulting in connection timeouts.
Original: * The grandmaster clock (T-GM) transitions to the Locked state too soon. This is a known issue that happens before the Digital Phase-Locked Loop (DPLL) completes its change to the Locked-HO-Acquired state, and after the Global Navigation Satellite Systems (GNSS) time source is restored. (link:https://issues.redhat.com/browse/OCPBUGS-55466[*OCPBUGS-55466*]). 
Revised: * Curently, the grandmaster clock (T-GM) transitions to the `Locked` state before the Digital Phase-Locked Loop (DPLL) transitions to the `Locked-HO-Acquired` state, and after the Global Navigation Satellite Systems (GNSS) time source is restored. There is currently no workaround for this issue. (link:https://issues.redhat.com/browse/OCPBUGS-55466[*OCPBUGS-55466*]).
Original: * Previously, when viewing the list of installed Operators, an Operator appeared twice in the list. This duplication occurred when the currently selected project matched an Operator's default namespace while copied cluster service versions (CSVs) were disabled in the Operator Lifecycle Manager (OLM). With this release, the Operator appears once. (link:https://issues.redhat.com/browse/OCPBUGS-55733[OCPBUGS-55733]). 
Revised: * Previously, when you viewed the list of installed Operators, an Operator appeared twice in the list because the currently selected project matched an Operator's default namespace while the copied cluster service versions (CSVs) were disabled in the Operator Lifecycle Manager (OLM). With this release, the Operator appears once. (link:https://issues.redhat.com/browse/OCPBUGS-55733[OCPBUGS-55733]).
Original: * Previously, when a validating webhook was created for a user or group on a resource managed by the OpenShift OAuth API server, the webhook was not triggered because the OAuth APIs were not reachable through the konnectivity tunnel. With this release, the issue is resolved by adding a `konnectivity-proxy` sidecar to the OAuth API server, enabling proper communication between the server and the data plane. (link:https://issues.redhat.com/browse/OCPBUGS-55266[OCPBUGS-55266]).
Revised: * Previously, when you created a validating webhook for a user or group on a resource managed by the OpenShift OAuth API server, the webhook was not triggered because the OAuth APIs were not reachable through the konnectivity tunnel. With this release, adding a `konnectivity-proxy` sidecar to the OAuth API server resolves the issue and enables proper communication between the server and the data plane. (link:https://issues.redhat.com/browse/OCPBUGS-55266[OCPBUGS-55266]).
Original: Role names are limited to a maximum length of 64 characters in AWS IAM. When the user-specified prefix for a cluster is longer than 20 characters, the role name is truncated to observe this 64 character maximum in AWS IAM.
Revised: Role names are limited to a maximum length of 64 characters in AWS IAM. When the user-specified prefix for a cluster is longer than 20 characters, the role name is truncated to observe this 64-character maximum in AWS IAM.
Original: * **`rosa create network` command added for {hcp-title} clusters.** You can now use the `rosa create network` command when creating {hcp-title} clusters to create networks using AWS CloudFormation templates. This helper command is intended to help create and configure a VPC for use with {hcp-title}. This command also supports zero egress clusters. For more information, see xref:../cli_reference/rosa_cli/rosa-manage-objects-cli.adoc#rosa-create-network_rosa-managing-objects-cli[create network].
Revised: This command also supports {zero-egress} clusters. For more information, see xref:../cli_reference/rosa_cli/rosa-manage-objects-cli.adoc#rosa-create-network_rosa-managing-objects-cli[create network].
Original: [id="rosa-prepare-am-resources-roles-operator"]
== Roles required to manage Operator features
//operator roles
//created per-cluster or per-OIDC provider if that is shared between clusters
Cluster-specific Operator roles (`operator-roles` in the ROSA CLI) obtain the temporary permissions required to perform cluster operations that are provided by Operators, such as managing back-end storage, ingress, and registry. These roles are required for every cluster, as several Operators are used to provide cluster features by default.
Revised: * link:https://docs.aws.amazon.com/rosa/latest/userguide/security-iam-awsmanpol.html[AWS Managed IAM policies for {hcp-title} clusters]
Original: Before using the {product-title} (ROSA) CLI (`rosa`) to create {hcp-title-first} clusters, create the required account-wide roles and policies, including the Operator policies.
{hcp-title} clusters require account and Operator roles with AWS managed policies attached. Customer managed policies are not supported. For more information regarding AWS managed policies for {hcp-title} clusters, see link:https://docs.aws.amazon.com/ROSA/latest/userguide/security-iam-awsmanpol-account-policies.html[AWS managed policies for ROSA account roles].
Revised: Specific AWS-managed policies for {hcp-title} must be attached to each role. Customer-managed policies must not be used with these required account roles. For more information regarding AWS managed policies for {hcp-title} clusters, see link:https://docs.aws.amazon.com/ROSA/latest/userguide/security-iam-awsmanpol-account-policies.html[AWS managed policies for ROSA].
Original: 
To create and manage clusters:: Several account-wide roles are required to create and manage ROSA clusters. These roles only need to be created once per AWS account, and do not need to be created fresh for each cluster. You can specify your own prefix, or use the default prefix (`ManagedOpenShift`).
The following account-wide roles are required:

** `<prefix>-HCP-ROSA-Worker-Role`
** `<prefix>-HCP-ROSA-Support-Role`
** `<prefix>-HCP-ROSA-Installer-Role`
endif::openshift-rosa-hcp[]
To manage cluster features provided by Operators:: Cluster-specific Operator roles (`operator-roles` in the ROSA CLI), obtain the temporary permissions required to carry out cluster operations for features provided by Operators, such as managing back-end storage, ingress, and registry. This requires the configuration of an OpenID Connect (OIDC) provider, which connects to AWS Security Token Service (STS) to authenticate Operator access to AWS resources.
Revised: To use Operator-managed cluster capabilities:: Some cluster capabilities, including several capabilities provided by default, are managed using Operators. Cluster-specific Operator roles (`operator-roles` in the ROSA CLI) are required to use these capabilities. These roles are used to obtain the temporary permissions required to carry out cluster operations such as managing back-end storage, ingress, and registry. This requires the configuration of an OpenID Connect (OIDC) provider, which connects to AWS Security Token Service (STS) to authenticate Operator access to AWS resources.
Original: 
To create and manage clusters:: Several account-wide roles are required to create and manage ROSA clusters. These roles only need to be created once per AWS account, and do not need to be created fresh for each cluster. You can specify your own prefix, or use the default prefix (`ManagedOpenShift`).
The following account-wide roles are required:

** `<prefix>-HCP-ROSA-Worker-Role`
** `<prefix>-HCP-ROSA-Support-Role`
** `<prefix>-HCP-ROSA-Installer-Role`
endif::openshift-rosa-hcp[]
To manage cluster features provided by Operators:: Cluster-specific Operator roles (`operator-roles` in the ROSA CLI), obtain the temporary permissions required to carry out cluster operations for features provided by Operators, such as managing back-end storage, ingress, and registry. This requires the configuration of an OpenID Connect (OIDC) provider, which connects to AWS Security Token Service (STS) to authenticate Operator access to AWS resources.
Operator roles are required for every cluster, as several Operators are used to provide cluster features by default.
Revised: | Role name | AWS-managed policy name
Original: * link:https://docs.aws.amazon.com/rosa/latest/userguide/security-iam-rosa-classic-account-policies.html[AWS IAM account-wide policies for ROSA Classic clusters]
* link:https://docs.aws.amazon.com/rosa/latest/userguide/security-iam-rosa-classic-operator-policies.html[AWS IAM Operator policies for ROSA Classic clusters]
Revised: * link:https://docs.aws.amazon.com/rosa/latest/userguide/security-iam-rosa-classic-account-policies.html[AWS IAM account-wide policies for ROSA Classic clusters] (AWS documentation)
* link:https://docs.aws.amazon.com/rosa/latest/userguide/security-iam-rosa-classic-operator-policies.html[AWS IAM Operator policies for ROSA Classic clusters] (AWS documentation)
Original: * link:https://docs.aws.amazon.com/rosa/latest/userguide/security-iam-awsmanpol.html[AWS Managed IAM policies for {hcp-title} clusters]
Revised: * link:https://docs.aws.amazon.com/rosa/latest/userguide/security-iam-awsmanpol.html[AWS Managed IAM policies for {hcp-title} clusters] (AWS documentation)
Original: [id="rosa-prepare-am-resources-roles-operator"]
== Roles required to manage Operator features
//operator roles
//created per-cluster or per-OIDC provider if that is shared between clusters
Cluster-specific Operator roles (`operator-roles` in the ROSA CLI) obtain the temporary permissions required to perform cluster operations that are provided by Operators, such as managing back-end storage, ingress, and registry. These roles are required for every cluster, as several Operators are used to provide cluster features by default.
Revised: * link:https://docs.aws.amazon.com/rosa/latest/userguide/security-iam-rosa-classic-account-policies.html[AWS IAM account-wide policies for ROSA Classic clusters] (AWS documentation)
endif::openshift-rosa-hcp[]
ifdef::openshift-rosa-hcp[]
* link:https://docs.aws.amazon.com/rosa/latest/userguide/security-iam-awsmanpol.html[AWS Managed IAM policies for {hcp-title} clusters] (AWS documentation)
endif::openshift-rosa-hcp[]
Original: [id="rosa-prepare-am-resources-roles-operator"]
== Roles required to manage Operator features
//operator roles
//created per-cluster or per-OIDC provider if that is shared between clusters
Cluster-specific Operator roles (`operator-roles` in the ROSA CLI) obtain the temporary permissions required to perform cluster operations that are provided by Operators, such as managing back-end storage, ingress, and registry. These roles are required for every cluster, as several Operators are used to provide cluster features by default.
=== Required OIDC authentication resources
include::modules/rosa-sts-byo-oidc.adoc[leveloffset=+3]
Revised: * link:https://docs.aws.amazon.com/rosa/latest/userguide/security-iam-rosa-classic-operator-policies.html[Required AWS IAM Operator policies for ROSA Classic clusters] (AWS documentation)
endif::openshift-rosa-hcp[]
ifdef::openshift-rosa-hcp[]
* link:https://docs.aws.amazon.com/rosa/latest/userguide/security-iam-awsmanpol.html[AWS Managed IAM policies for {hcp-title} clusters] (AWS documentation)
endif::openshift-rosa-hcp[]
Original: Resolution:: By default, {rh-rhacm} does not match policies and `ManagedCluster` CRs until the `ManagedCluster` CRs are available. The {rh-rhacm} policy generator automatically generates the `Placement` CR which includes the tolerations needed to enable the match before the `ManagedCluster` CRs are available. If you use a custom `Placement` CR instead, you should include the tolerations in that `Placement` CR.
Revised: Resolution:: By default, {rh-rhacm} does not match policies and `ManagedCluster` CRs until the `ManagedCluster` CRs are available. The {rh-rhacm} `PolicyGenerator` automatically generates the `Placement` CR which includes the tolerations needed to enable the match before the `ManagedCluster` CRs are available. If you use a custom `Placement` CR instead, you should include the tolerations in that `Placement` CR.
Original: The {rh-rhacm} `PolicyGenerator` uses the generated `Placement` CR to do this automatically. 
By default, this `Placement` CR includes the necessary tolerations. 
This ensures proper {cgu-operator} behavior. 
Revised: The {rh-rhacm} `PolicyGenerator` uses the generated `Placement` CR to do this automatically.
By default, this `Placement` CR includes the necessary tolerations to ensure proper {cgu-operator} behavior.
Original: For more information, see xref:../installing/installing_azure/ipi/installing-azure-network-customizations.adoc#installation-azure-tested-machine-types_installing-azure-network-customizations[Tested instance types for {azure-short}] and link:https://learn.microsoft.com/en-us/azure/?product=popular[{azure-short} documentation] (Microsoft documentation).
Revised: For the Lsv4 and Lasv4 machine series', the following instances types have been tested:
Original: * Previously, the pod placement operand did not support authenticating registries using wildcard entries in the hostname part of their pull secret. This caused inconsistent behavior with Kubelet when pulling images, because Kubelet supported such wildcards while the operand required exact hostname matches. As a result, image pulls could fail unexpectedly when registries used wildcard hostnames.
Revised: * Previously, the pod placement operand did not support authenticating registries using wildcard entries in the hostname of their pull secret. This caused inconsistent behavior with Kubelet when pulling images, because Kubelet supported wildcard entries while the operand required exact hostname matches. As a result, image pulls could fail unexpectedly when registries used wildcard hostnames.
Original: * Previously, an operator would incorrectly appear twice in the installed operators list if the current project matched its default namespace and the copied CSVs were disabled in Operator Lifecycle Manager (OLM). With this release, the operator displays only once. (link:https://issues.redhat.com/browse/OCPBUGS-55942[OCPBUGS-55942])
Revised: * Previously, an operator would incorrectly appear twice in the installed operators list if the current project matched its default namespace and the copied CSVs were disabled in {olm-first}. With this release, the operator displays only once. (link:https://issues.redhat.com/browse/OCPBUGS-55942[OCPBUGS-55942])