gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: With this release, you can customize the prefix of machine names for machines created by the control plane machine set.
This is enabled by modifying the `spec.machineNamePrefix` parameter of the `ControlPlaneMachineSet` custom resource.
Revised: With this release, you can customize the prefix of machine names for machines created by the control plane machine set by modifying the `spec.machineNamePrefix` parameter of the `ControlPlaneMachineSet` custom resource.
With this release, you can customize the prefix of machine names for machines created by the control plane machine set.
This feature is enabled by modifying the `spec.machineNamePrefix` parameter of the `ControlPlaneMachineSet` custom resource.
Original: |
// | xref :../observability/logging/cluster-logging.adoc#cluster-logging[Logging]
| link:https://access.redhat.com/support/policy/updates/openshift#ocp4_phases[{product-title} Life Cycle]

|
| link:https://www.openshift.com/blog/tag/logging[Blogs about logging]

Develop and deploy containerized applications with {product-title}. {product-title} is a platform for developing and deploying containerized applications. Read the following {product-title} documentation, so that you can better understand {product-title} functions:
[options="header",cols="2*"]
a|* xref:../applications/creating_applications/odc-creating-applications-using-developer-perspective.adoc#odc-creating-applications-using-developer-perspective[Creating applications]
* xref:../applications/creating_applications/odc-creating-applications-using-developer-perspective.adoc#odc-creating-applications-using-developer-perspective[Creating applications using the Developer perspective]

| xref:../architecture/understanding-development.adoc#understanding-development[Understand {product-title} development]
a|* xref:../applications/projects/working-with-projects.adoc#working-with-projects[Work with projects]
Revised: a|* xref:../architecture/understanding-development.adoc#understanding-development[Understanding {product-title} development]
Original: |
// | xref :../observability/logging/cluster-logging.adoc#cluster-logging[Logging]
| link:https://access.redhat.com/support/policy/updates/openshift#ocp4_phases[{product-title} Life Cycle]

|
| link:https://www.openshift.com/blog/tag/logging[Blogs about logging]

Develop and deploy containerized applications with {product-title}. {product-title} is a platform for developing and deploying containerized applications. Read the following {product-title} documentation, so that you can better understand {product-title} functions:
[options="header",cols="2*"]
a|* xref:../applications/creating_applications/odc-creating-applications-using-developer-perspective.adoc#odc-creating-applications-using-developer-perspective[Creating applications]
* xref:../applications/creating_applications/odc-creating-applications-using-developer-perspective.adoc#odc-creating-applications-using-developer-perspective[Creating applications using the Developer perspective]

| xref:../architecture/understanding-development.adoc#understanding-development[Understand {product-title} development]
a|* xref:../applications/projects/working-with-projects.adoc#working-with-projects[Work with projects]
Revised: * xref:../applications/projects/working-with-projects.adoc#working-with-projects[Working with projects]
Original: |
// | xref :../observability/logging/cluster-logging.adoc#cluster-logging[Logging]
| link:https://access.redhat.com/support/policy/updates/openshift#ocp4_phases[{product-title} Life Cycle]

|
| link:https://www.openshift.com/blog/tag/logging[Blogs about logging]

Develop and deploy containerized applications with {product-title}. {product-title} is a platform for developing and deploying containerized applications. Read the following {product-title} documentation, so that you can better understand {product-title} functions:
[options="header",cols="2*"]
a|* xref:../applications/creating_applications/odc-creating-applications-using-developer-perspective.adoc#odc-creating-applications-using-developer-perspective[Creating applications]
* xref:../applications/creating_applications/odc-creating-applications-using-developer-perspective.adoc#odc-creating-applications-using-developer-perspective[Creating applications using the Developer perspective]

| xref:../architecture/understanding-development.adoc#understanding-development[Understand {product-title} development]
a|* xref:../applications/projects/working-with-projects.adoc#working-with-projects[Work with projects]
a|* xref:../cicd/builds/understanding-image-builds.adoc#understanding-image-builds[Builds]
* xref:../cicd/builds/understanding-image-builds.adoc#understanding-image-builds[Understand image builds]
Revised: | xref:../cicd/builds/understanding-image-builds.adoc#understanding-image-builds[Understanding image builds]
Original: * {product-title} clusters that are installed on {aws-short} in the Mexico Central region (`mx-central-1`) cannot be destroyed. (link:https://issues.redhat.com/browse/OCPBUGS-53116[*OCPBUGS-53116*])
Revised: * {product-title} clusters that are installed on {aws-short} in the Mexico Central region (`mx-central-1`) cannot be destroyed. (link:https://issues.redhat.com/browse/OCPBUGS-56020[*OCPBUGS-56020*])
Original: [IMPORTANT]
====
Red{nbsp}Hat does not provide a backup method for
ifndef::openshift-rosa-hcp[]
ROSA clusters that use STS.
endif::openshift-rosa-hcp[]
ifdef::openshift-rosa-hcp[]
{hcp-title} clusters.
endif::openshift-rosa-hcp[]
It is critical that customers have a backup plan for their applications and application data.
====
Application and application data backups are not a part of the
ifdef::openshift-rosa-hcp[]
{hcp-title} service.
endif::openshift-rosa-hcp[]
ifndef::openshift-rosa-hcp[]
{product-title} service.
ifndef::openshift-rosa-hcp[]
[%collapsible]
The table below only applies to non-STS clusters. The following components are used by Red Hat in extenuating circumstances.

//Verify if the corresponding tables in policy-incident.adoc and rosa-policy-incident.adoc also need to be updated.

[cols= "3a,2a,2a,3a",options="header"]

|===
|Component
|Snapshot frequency
|Retention
|Notes

.2+|Full object store backup
|Daily
|7 days
.2+|This is a full backup of all Kubernetes objects like etcd. No persistent volumes (PVs) are backed up in this backup schedule.

|Weekly
|30 days

|Full object store backup
|Hourly
|24 hour
|This is a full backup of all Kubernetes objects like etcd. No PVs are backed up in this backup schedule.

|Node root volume
|Never
|N/A
|Nodes are considered to be short-term. Nothing critical should be stored on a node's root volume.
|===

endif::openshift-rosa-hcp[]
Revised: Customers are solely responsible for backing up and restoring their applications and application data. For more information about customer responsibilities, see "Shared responsibility matrix".
Original: * Previously, a bug fix altered the availability set configuration by changing the fault domain count to use the maximum available value instead of being fixed at 2. This inadvertently caused scaling issues for MachineSets created prior to the bug fix, as the controller attempted to modify immutable availability sets. With this release, availability sets are no longer modified after creation, allowing affected MachineSets to scale properly. (link:https://issues.redhat.com/browse/OCPBUGS-56655[OCPBUGS-56655])
Revised: * Previously, a bug fix altered the availability set configuration by changing the fault domain count to use the maximum available value instead of being fixed at 2. This inadvertently caused scaling issues for `MachineSets` created prior to the bug fix, as the controller attempted to modify immutable availability sets. With this release, availability sets are no longer modified after creation, allowing affected `MachineSets` to scale properly. (link:https://issues.redhat.com/browse/OCPBUGS-56655[OCPBUGS-56655])
Original: * Previously, there was no communication between a `localnet` pod and a pod in the default network, when both pods were on the same node. With this release, an update fixes this problem when the endpoints were on a different node. (link:https://issues.redhat.com/browse/OCPBUGS-56244[OCPBUGS-56244])
Revised: * Previously, there was no communication between a `localnet` pod and a pod in the default network, when both pods were on the same node. With this release, an update fixes this problem when the endpoints are on a different node. (link:https://issues.redhat.com/browse/OCPBUGS-56244[OCPBUGS-56244])
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-55800[OCPBUGS-55800])
Revised: * Previously, the Samples 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 Samples 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-55800[OCPBUGS-55800])
Original: * Previously, the Grandmaster Timekeeper (T-GM) operation unexpectedly set the Precision Time Protocol (PTP) announce message internal signal flags incorrectly. This caused the loss of time synchronization across the network. With this release, the PTP announce message flags are correctly initialized ensuring accurate and standardized time synchronization information is disseminated across the network. (link:https://issues.redhat.com/browse/OCPBUGS-55740[OCPBUGS-55740])
Revised: * Previously, the Grandmaster Timekeeper (T-GM) operation unexpectedly set the Precision Time Protocol (PTP) announce message internal signal flags incorrectly. This caused the loss of time synchronization across the network. With this release, the PTP announce message flags are correctly initialized, ensuring accurate and standardized time synchronization information is disseminated across the network. (link:https://issues.redhat.com/browse/OCPBUGS-55740[OCPBUGS-55740])
Original: * Previously, a bug fix altered the availability set configuration by changing the fault domain count to use the maximum available value instead of being fixed at 2. This inadvertently caused scaling issues for `MachineSets created prior to the bug fix, as the controller attempted to modify immutable availability sets. With this release, availability sets are no longer modified after creation, allowing affected `MachineSets` to scale properly. (link:https://issues.redhat.com/browse/OCPBUGS-56655[OCPBUGS-56655])
Revised: * Previously, a bug fix altered the availability set configuration by changing the fault domain count to use the maximum available value instead of being fixed at 2. This inadvertently caused scaling issues for `MachineSet` objects created prior to the bug fix, because the controller attempted to modify immutable availability sets. With this release, availability sets are no longer modified after creation, allowing affected `MachineSet` objects to scale properly. (link:https://issues.redhat.com/browse/OCPBUGS-56655[OCPBUGS-56655])
Original: * Red Hat supports the configuration and operation of {product-title-short} Central connected to that database. However, support for database-specific operations such as backup and restore, performance diagnosis and potential tuning, software and version upgrades, and HA/DR operation falls under 3rd Party Support. Manually upgrading or customizing your database outside of a full platform upgrade also limit supportability.
Revised: * Red Hat supports the configuration and operation of {product-title-short} Central connected to that database. However, support for database-specific operations such as backup and restore, performance diagnosis and potential tuning, software and version upgrades, and high availability/disaster recovery operation falls under third-party support. Manually upgrading or customizing your database outside of a full platform upgrade also limits supportability.
Original: ==== Support for using the Gateway API to configure cluster Ingress traffic
We will have details here when {product-title} {product-version} is released.
We will have details here when {product-title} {product-version} is released.
Revised: With this release, {product-title} manages the lifecycle of Gateway API CRDs. This means that the Ingress Operator handles the required versioning and management of resources. Any Gateway API resources created in a previous {product-title} version must be re-created and redeployed so that it conforms to the specifications required by the Ingress Operator.
Original: ==== Support for using the Gateway API to configure cluster Ingress traffic
We will have details here when {product-title} {product-version} is released.
Revised: ==== Support for using the Gateway API to configure cluster ingress traffic (General Availability)
With this release, support for managing ingress cluster traffic using Gateway API resources is Generally Available. Gateway API provides a robust networking solution within the transport layer, L4, and the application layer, L7, for {product-title} clusters using a standardized open source ecosystem.
Original: = Deploying workflows in Dev mode
You can deploy your local workflow on {ocp-product-title} in Dev mode. You can use this deployment to experiment and modify your workflow directly on the cluster, seeing changes almost immediately. Dev mode is designed for development and testing purposes. It is ideal for initial development stages and for testing new changes.
Revised: You can deploy your local workflow on {ocp-product-title} using the Dev profile. You can use this deployment to experiment and modify your workflow directly on the cluster, seeing changes almost immediately. Dev profile is designed for development and testing purposes. Because it automatically reloads the workflow without restarting the container, it is ideal for initial development stages and for testing workflow changes in a live environment.
Original: = Deploying workflows
You can deploy the {ServerlessLogicProductShortName} workflows on the cluster in two modes: Dev mode and Preview mode.
== Deploying workflows in Preview mode
You can deploy your local workflow on {ocp-product-title} in Preview mode. This allows you to experiment and modify your workflow directly on the cluster, seeing changes almost immediately. Preview mode is used for final testing and validation before deploying to production. It also ensures that workflows will run smoothly in a production-like setting.
Revised: You can deploy your local workflow on {ocp-product-title} using the Preview profile. This allows you to validate and test workflows in a production-like environment directly on the cluster. Preview profile is ideal for final testing and validation before moving workflows to production, as well as for quick iteration without directly managing the build pipeline. It also ensures that workflows run smoothly in a production-like setting.
Original: You can deploy your local workflow on {ocp-product-title} in GitOps profile. The GitOps profile provides full control over the workflow container image by allowing you to build and manage the image externally, typically through a CI/CD pipeline such as ArgoCD or Tekton. When a container image is defined in the `SonataFlow` custom resource (CR), the Operator automatically assumes the GitOps profile is being used and it does not attempt to build or modify the image in any way.
Revised: You can deploy your local workflow on {ocp-product-title} using the GitOps profile. The GitOps profile provides full control over the workflow container image by allowing you to build and manage the image externally, typically through a CI/CD pipeline such as ArgoCD or Tekton. When a container image is defined in the `SonataFlow` custom resource (CR), the Operator automatically assumes the GitOps profile is being used and it does not attempt to build or modify the image in any way.
Original: <1> The `flow` definition must match the workflow definition used during the build process. When you deploy your workflow in GitOps profile, the operator compares this definition with the workflow files embedded in the container image. If they do not match, the deployment fails.
Revised: <1> The `flow` definition must match the workflow definition used during the build process. When you deploy your workflow using the GitOps profile, the Operator compares this definition with the workflow files embedded in the container image. If the definition and files do not match, the deployment fails.
Original: .. Check that the `MachineOSBuild` object is `READY`. When the `SUCCEEDED` value is `True`, the build is complete.
+
[source,terminal]
----
$ oc get machineosbuild
----
+
.Example output showing that the `MachineOSBuild` object is ready
[source,terminal]
----
NAME                                                     PREPARED   BUILDING   SUCCEEDED   INTERRUPTED   FAILED   AGE
layered-image-ad5a3cad36303c363cf458ab0524e7c0-builder   False      False      True        False         False    43s
----

.. Edit the nodes where you want to deploy the custom layered image by adding a label for the machine config pool you specified in the `MachineOSConfig` object:
Revised: .. Check that the `MachineOSBuild` object is ready, by running the following command:

[source,terminal]
$ oc get machineosbuild

When the `SUCCEEDED` value is `True`, the build is complete:

.Example output showing that the `MachineOSBuild` object is ready
[source,terminal]
NAME                                                     PREPARED   BUILDING   SUCCEEDED   INTERRUPTED   FAILED   AGE
layered-image-ad5a3cad36303c363cf458ab0524e7c0-builder   False      False      True        False         False    43s
Original: - Integrating with the Quay public repository (registry): This method does not require authentication.
- Integrating with a Quay private registry by using a robot account: This method requires that you create a robot account to use with Quay (recommended). See the link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/html/use_red_hat_quay/use-quay-manage-repo#allow-robot-access-user-repo[Quay documentation] for more information.
- Integrating with Quay to use the Quay scanner rather than the {product-title-short} scanner:  This method uses the API and requires an OAuth token for authentication. See "Integrating with Quay Container Registry to scan images" in the "Additional Resources" section.
Revised: ** By using keyless authentication with external secret: This method uses OIDC federation and the External Secrets Operator (ESO). For more information, see "Enabling Quay registry keyless authentication using external secret".
Original: - Integrating with the Quay public repository (registry): This method does not require authentication.
- Integrating with a Quay private registry by using a robot account: This method requires that you create a robot account to use with Quay (recommended). See the link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/html/use_red_hat_quay/use-quay-manage-repo#allow-robot-access-user-repo[Quay documentation] for more information.
- Integrating with Quay to use the Quay scanner rather than the {product-title-short} scanner:  This method uses the API and requires an OAuth token for authentication. See "Integrating with Quay Container Registry to scan images" in the "Additional Resources" section.
Revised: * Integrating with Quay to use the Quay scanner rather than the {product-title-short} scanner:  This method uses the API and requires an OAuth token for authentication. For more information, see "Integrating with Quay Container Registry to scan images" in the "Additional resources" section.
Original: For validating images stored in Quay private registries, you can configure {product-title-short} to use keyless authentication with Red Hat Quay registries by leveraging External Secrets Operator (ESO) and OpenID Connect (OIDC) federation.
Revised: For validating images stored in Quay private registries, you can configure {product-title-short} to use keyless authentication with Red{nbsp}Hat Quay registries. This method uses the External Secrets Operator (ESO) and OpenID Connect (OIDC) federation.
Original: - Integrating with the Quay public repository (registry): This method does not require authentication.
- Integrating with a Quay private registry by using a robot account: This method requires that you create a robot account to use with Quay (recommended). See the link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/html/use_red_hat_quay/use-quay-manage-repo#allow-robot-access-user-repo[Quay documentation] for more information.
- Integrating with Quay to use the Quay scanner rather than the {product-title-short} scanner:  This method uses the API and requires an OAuth token for authentication. See "Integrating with Quay Container Registry to scan images" in the "Additional Resources" section.
Revised: ** By using a robot account: This method requires that you create a robot account to use with Quay (recommended). See the link:https://docs.redhat.com/en/documentation/red_hat_quay/3.14/html/about_quay_io/allow-robot-access-user-repo[Red{nbsp}Hat Quay Robot Account overview] topic in Quay documentation for more information.
Original: * A robot account created in Red Hat Quay with OIDC federation configured. The issuer URL in the Quay robot identity federation configuration must match the service account token issuer of your {ocp} cluster, and the Subject `sub claim` must match the service account name and namespace that you configure in your cluster. See the link:https://docs.redhat.com/en/documentation/red_hat_quay/latest/html/about_quay_io/allow-robot-access-user-repo[Red Hat Quay Robot Account overview] topic in Quay documentation for more information.
Revised: * A robot account created in Red{nbsp}Hat Quay with OIDC federation configured.

* The issuer URL in the Quay robot identity federation configuration must match the service account token issuer of your {ocp} cluster.
* The `sub claim` subject must match the service account name and namespace that you configure in your cluster.

See the link:https://docs.redhat.com/en/documentation/red_hat_quay/latest/html/about_quay_io/allow-robot-access-user-repo[Red Hat Quay Robot Account overview] topic in Quay documentation for more information.
Original: . Define and apply the following Kubernetes resources. This creates a ServiceAccount, a `QuayAccessToken` generator resource (provided by the ESO installation), and an `ExternalSecret` resource that uses the generator to create a `kubernetes.io/dockerconfigjson` secret in the specified namespace.
Revised: . Define and apply the following Kubernetes resources. This example creates a `ServiceAccount` resource, a `QuayAccessToken` generator resource provided by the ESO installation, and an `ExternalSecret` resource that uses the generator to create a `kubernetes.io/dockerconfigjson` secret in the specified namespace.
Original: The keyless authentication method supports image scanning by using **delegated scanning**. For example:
[source,terminal]
----
$ roxctl image scan <image_name> --namespace=<namespace_where_secret_exists> <1>
----
<1> You must specify the namespace where you created the secret.
Revised: The keyless authentication method supports image scanning by using **delegated scanning**.

* Use delegated image scanning by running the following command:

[source,terminal]
$ roxctl image scan <image_name> --namespace=<namespace_where_secret_exists> <1>