gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: If you are creating a snapshot of a VM, a warning appears if the storage class of the disk has more than one volume snapshot class associated with it. In this case, you must specify one volume snapshot class; otherwise, any disk that has more than one volume snapshot class is excluded from the snapshots list.
Revised: If you are creating a snapshot of a VM, a warning appears if the storage class of the disk has more than one `VolumeSnapshotClass` associated with it. In this case, you must specify one volume snapshot class; otherwise, any disk that has more than one volume snapshot class is excluded from the snapshots list.
Original: .Example storage profile
[source,yaml]
----
apiVersion: cdi.kubevirt.io/v1beta1
kind: StorageProfile
metadata:
name: <unknown_provisioner_class>
# ...
spec: {}
status:
provisioner: <unknown_provisioner>
storageClass: <unknown_provisioner_class>
----
+
. Provide the needed attribute values in the storage profile:
Revised: . Specify the *accessModes* and *volumeMode* values you want to configure for the storage profile. For example:
Original: 
An empty `status` section in a storage profile indicates that a storage provisioner is not recognized by the Containerized Data Interface (CDI). Customizing a storage profile is necessary if you have a storage provisioner that is not recognized by CDI. In this case, the administrator sets appropriate values in the storage profile to ensure successful allocations.
Revised: If you are creating a snapshot of a virtual machine (VM), the storage class of the disk must specify one `VolumeSnapshotClass`. If there is more than more than one `VolumeSnapshotClass`, a warning is issued. Any disk that has more than one `VolumeSnapshotClass` is excluded from the snapshots list.
If you are creating a snapshot of a virtual machine (VM), you can only specify one `VolumeSnapshotClass` on the storage class of the disk. If there is more than more than one `VolumeSnapshotClass`, a warning is issued. A disk with more than one `VolumeSnapshotClass` are excluded from the snapshots list.
Original: You can use storage profiles to set a default cloning method for a storage class, creating a _cloning strategy_. Setting cloning strategies can be helpful, for example, if your storage vendor only supports certain cloning methods. It also allows you to select a method that limits resource usage or maximizes performance.
Revised: You can use storage profiles to set a default cloning method for a storage class by creating a _cloning strategy_. Setting cloning strategies can be helpful, for example, if your storage vendor only supports certain cloning methods. It also allows you to select a method that limits resource usage or maximizes performance.
Original: * `snapshot` is used by default when snapshots are configured. The CDI will use the snapshot method if it recognizes the storage provider and the provider supports Container Storage Interface (CSI) snapshots. This cloning strategy uses a temporary volume snapshot to clone the volume.
Revised: * `snapshot` is used by default when snapshots are configured. The Containerized Data Importer (CDI) will use the snapshot method if it recognizes the storage provider and the provider supports Container Storage Interface (CSI) snapshots. This cloning strategy uses a temporary volume snapshot to clone the volume.
Original: * `csi-clone` uses the CSI clone API to efficiently clone an existing volume without using an interim volume snapshot. Unlike `snapshot` or `copy`, which are used by default if no storage profile is defined, CSI volume cloning is only used when you specify it in the `StorageProfile` object for the provisioner's storage class.
Revised: * `csi-clone` uses the CSI clone API to efficiently clone an existing volume without using an interim volume snapshot. Unlike `snapshot` or `copy`, CSI volume cloning is only used when you specify it in the `StorageProfile` object for the provisioner's storage class.
Original: NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-bd7fbb9fc-wvbbt               1/1     Running   0          3m39s
cert-manager-cainjector-56cc5f9868-7g9z7   1/1     Running   0          4m5s
Revised: NAME                                                              READY   STATUS    RESTARTS   AGE
zero-trust-workload-identity-manager-controller-manager-6c4djb5   1/1     Running   0          4m2s
Original: NAME                            DISPLAY                                       VERSION   REPLACES                        PHASE
cert-manager-operator.v1.13.0   cert-manager Operator for Red Hat OpenShift   1.13.0    cert-manager-operator.v1.12.1   Succeeded
Revised: NAME                                          DISPLAY                                VERSION   REPLACES   PHASE
zero-trust-workload-identity-manager.v0.1.0   Zero Trust Workload Identity Manager   0.1.0                Succeeded
Original: NAME                                                        READY   STATUS    RESTARTS   AGE
cert-manager-operator-controller-manager-695b4d46cb-r4hld   2/2     Running   0          7m4s
Revised: NAME                                                              READY   STATUS      RESTARTS   AGE
zero-trust-workload-identity-manager-controller-manager-68x5m9z   1/1     Running     0          3m54s
Original: Attestation is the process by which the identity of nodes and workloads are verified before SPIFFE IDs and SVIDs are issued. The SPIRE server gathers attributes of both the workload and node that the SPIRE Agent runs on and then compares them to a set of selectors defined when the workload was registered. If the comparison is successful, the entities are provided with credentials. This ensures that only legitimate and expected entities within the trust domain receive cryptographic identities. The two main types of attestation in SPIFFE/SPIRE are:
Revised: Attestation is the process by which the identity of nodes and workloads are verified before SPIFFE IDs and SVIDs are issued. The SPIRE server gathers attributes of both the workload and node that the SPIRE Agent runs on, and then compares them to a set of selectors defined when the workload was registered. If the comparison is successful, the entities are provided with credentials. This ensures that only legitimate and expected entities within the trust domain receive cryptographic identities. The two main types of attestation in SPIFFE/SPIRE are:
Original: The SPIFFE IDs are contained in the {svid-full}. SVIDs are used by workloads to verify their identity to other workloads so the workloads can communicate with each other. The two main SVID formats are:
Revised: The SPIFFE IDs are contained in the {svid-full}. SVIDs are used by workloads to verify their identity to other workloads so that the workloads can communicate with each other. The two main SVID formats are:
Original: The SPIRE agent acts as a secure intermediary between the SPIRE server and the workloads running on a node. It performs node attestation against the server as well as workload attestation againt applications running on the node. The SPIRE agent is also responsible for retrieving, delivering, and renewing SVIDs. A SPIRE agent runs on every node on which an identified workload runs.
Revised: The SPIRE agent acts as a secure intermediary between the SPIRE server and the workloads running on a node. It performs node attestation against the server, as well as workload attestation against applications running on the node. The SPIRE agent is also responsible for retrieving, delivering, and renewing SVIDs. A SPIRE agent runs on every node on which an identified workload runs.
Original: Attestation is the process by which the SPIRE server verifies the identity of both nodes and workloads before issuing them SPIFFE IDs and SVIDs. The SPIRE server gathers attributes of both the workload and node that the SPIRE Agent runs on and then compares them to a set of selectors defined when the workload was registered. If the comparison is successful, the entities are providedThis ensures that only legitimate and expected entities within the trust domain receive cryptographic identities. The two main types of attestation in SPIFFE/SPIRE are:
Revised: Attestation is the process by which the SPIRE server verifies the identity of both nodes and workloads before issuing them SPIFFE IDs and SVIDs. The SPIRE server gathers attributes of both the workload and node that the SPIRE Agent runs on, and then compares them to a set of selectors defined when the workload was registered. If the comparison is successful, the entities are provided. This ensures that only legitimate and expected entities within the trust domain receive cryptographic identities. The two main types of attestation in SPIFFE/SPIRE are:
Original: . To deploy a SPIRE server, agent or spife-csi-drivers as a daemonset, or deploy the SPIRE OIDC discovery provider, you need to deploy a custom resource of a certain type and name it `cluster`. The custom resource types are as follows:
Revised: . To deploy a SPIRE server, agent or spife-csi-drivers as a daemonset, or deploy the SPIRE OIDC discovery provider, deploy a custom resource of a certain type, and name it `cluster`. The custom resource types are as follows:
Original: .. Alternatively, delete deployments of the zero trust workload identity manager components such as `zero trust workload identity manager`, `cainjector` and `webhook` present in the `zero trust workload identity manager` namespace by using the command-line interface (CLI).
Revised: .. Alternatively, delete deployments of the zero trust workload identity manager components, such as `zero trust workload identity manager`, `cainjector`, and `webhook` present in the `zero trust workload identity manager` namespace by using the command-line interface (CLI).
Original: . Verify that zero trust workload identity manager pods are up and running by entering the following command:
+
[source,terminal]
----
$ oc get pods -n zero-trust-workload-identity-manager
----
+
.Example output
[source,terminal]
----
NAME                                                            READY   STATUS    RESTARTS   AGE
zero-trust-workload-identity-manager-controller-manager-6c4djb  1/1     Running   0          4m2s
----
Revised: . Verify that the zero-trust-workload-identity-manager controller-manager deployment is ready and available by running the following command:

[source,terminal]
$ oc get deployment -l name=zero-trust-workload-identity-manager -n zero-trust-workload-identity-manager

.Example output
[source,terminal]
NAME                                                      READY   UP-TO-DATE   AVAILABLE   AGE
zero-trust-workload-identity-manager-controller-manager   1/1     1            1           43m
Original: . Verify that the status {zero-trust-full} is `Running` by running the following command:
+
[source, terminal]
----
$ oc get pods -n zero-trust-workload-identity-manager
----
+
.Example output
[source, terminal]
----
NAME                                                             READY   STATUS    RESTARTS   AGE
zero-trust-workload-identity-manager-controller-manager-68x5m9z  1/1     Running   0          3m54s
----
Revised: . Verify that the zero-trust-workload-identity-manager controller-manager deployment is ready and available by running the following command:

[source, terminal]
$ oc get deployment -l name=zero-trust-workload-identity-manager -n zero-trust-workload-identity-manager

.Example output
[source, terminal]
NAME                                                      READY   UP-TO-DATE   AVAILABLE   AGE
zero-trust-workload-identity-manager-controller-manager   1/1     1            1           43m
Original: . To deploy a SPIRE server, agent or spife-csi-drivers as a daemonset, or deploy the SPIRE OIDC discovery provider, you need to deploy a custom resource of a certain type and name it `cluster`. The custom resource types are as follows:
Revised: . To deploy the SPIRE server, SPIRE agent, SPIFFE CSI Driver, and SPIRE OIDC discovery provider, you need to create a custom resource of each certain type and name it `cluster`. The custom resource types are as follows:
Original: * SPIRE server - `SpireServerConfig`
* SPIRE agent - `SpireAgentConfig`
* SPIFFE CSI Driver - `SpiffeCSIDriverConfig`
* SPIRE OIDC discovery provider - `SpireOIDCDiscoveryProviderConfig`
Revised: * SPIRE server - `SpireServer`
* SPIRE agent - `SpireAgent`
* SPIFFE CSI Driver - `SpiffeCSIDriver`
* SPIRE OIDC discovery provider - `SpireOIDCDiscoveryProvider`
Original: $ oc delete SpireServerConfig cluster
$ oc delete SpireAgentConfig cluster
$ oc delete SpiffeCSIDriverConfig cluster
$ oc delete SpireOIDCDiscoveryProviderConfig cluster
----

Revised: $ oc delete SpireServer cluster
$ oc delete SpireAgent cluster
$ oc delete SpiffeCSIDriver cluster
$ oc delete SpireOIDCDiscoveryProvider cluster
Original: $ oc delete crd spireserverconfigs.operator.openshift.io
$ oc delete crd spireagentconfigs.operator.openshift.io
$ oc delete crd spiffecsidriverconfigs.operator.openshift.io
$ oc delete crd spireoidcdiscoveryproviderconfigs.operator.openshift.io
Revised: $ oc delete crd spireservers.operator.openshift.io
$ oc delete crd spireagents.operator.openshift.io
$ oc delete crd spiffecsidrivers.operator.openshift.io
$ oc delete crd spireoidcdiscoveryproviders.operator.openshift.io
Original: == NetworkPolicies and external IPs in OVN-Kubernetes
In OVN-Kubernetes, `NetworkPolicies` enforce strict isolation rules. If a service is exposed using an external IP, `NetworkPolicies` can block access from other namespaces unless explicitly configured.
Revised: In OVN-Kubernetes, the `NetworkPolicy` custom resource (CR) enforces strict isolation rules. If a service is exposed using an external IP, a network policy can block access from other namespaces unless explicitly configured.
Original: * Previously, service deletion improperly handled API service association, resulting in API service unavailability. When combined with the `ClusterResourceOverride` deletion, the API service for `admission.autoscaling.openshift.io/v1` was unreachable, affecting operator installations. With this release, the `ClusterResourceOverride` deletion removes associated API services, and the API service remains accessible after deleting the `ClusterResourceOverride`.(link:https://issues.redhat.com/browse/OCPBUGS-55242[OCPBUGS-55242])
Revised: * Previously, service deletion improperly handled API service association, resulting in API service unavailability. When the `ClusterResourceOverride` resource was deleted, the `admission.autoscaling.openshift.io/v1` API service was unreachable, affecting Operator installations. With this release, deleting the `ClusterResourceOverride` resource removes associated API services, and the API service remains accessible after deleting the `ClusterResourceOverride` resource. (link:https://issues.redhat.com/browse/OCPBUGS-55242[OCPBUGS-55242])
Original: * Previously, a bug that was caused by missing `catalogd` certificate authorities (CA) resulted in failed {product-title} Operator Lifecycle Manager (OLMv1) installations. With this release,  an updated Operator Controller uses a new directory for CA certificates. This change improves the stability of the system, ensuring the correct installation of cluster extensions, and enhancing the user experience. (link:https://issues.redhat.com/browse/OCPBUGS-55172[OCPBUGS-55172]) 
Revised: * Previously, missing catalogd certificate authorities (CA) resulted in failed {olmv1-first} installations. With this release,  an updated Operator Controller uses a new directory for CA certificates. This change improves the stability of the system, ensuring the correct installation of cluster extensions, and enhancing the user experience. (link:https://issues.redhat.com/browse/OCPBUGS-55172[OCPBUGS-55172])
Original: * Previously, in {product-version} 4.16, a migration failure occurred after a reboot for users moving from OpenShift SDN to `OVNKubernetes` due to an interface configuration issue. The failure occurred because the `mtu-migration` service that was active before the `wait-for-primary-ip` service in the NMState-managed `br-ex`. With this release, the order of these services are reversed to ensure a successful migration and to prevent the `mtu-migration` service failure that occurs after the first reboot. (link:https://issues.redhat.com/browse/OCPBUGS-54817[OCPBUGS-54817])
Revised: * Previously, in {product-version} 4.16, a migration failure occurred after a reboot for users moving from OpenShift SDN to `OVNKubernetes` due to an interface configuration issue. The failure occurred because the `mtu-migration` service that was active before the `wait-for-primary-ip` service in the NMState-managed `br-ex` service. With this release, the order of these services are reversed to ensure a successful migration and to prevent the `mtu-migration` service failure that occurs after the first reboot. (link:https://issues.redhat.com/browse/OCPBUGS-54817[OCPBUGS-54817])
Original: * Previously, missing ClusterRole permissions for Cluster Network Operator (CNO) in `monitoring.coreos.com` and `monitoring.rhobs` APIs caused monitoring issues because of insufficient permissions. With this release, permissions for CNO to manage `servicemonitors` and `prometheusrules` exist. The CNO patches `servicemonitor` and `prometheusrules` objects in the `monitoring.coreos.com` API group, which corrects the monitoring issues. (link:https://issues.redhat.com/browse/OCPBUGS-54698[OCPBUGS-54698])
Revised: * Previously, missing cluster role permissions for Cluster Network Operator (CNO) in the `monitoring.coreos.com` and `monitoring.rhobs` APIs caused monitoring issues because of insufficient permissions. With this release, permissions for CNO to manage the `servicemonitors` and `prometheusrules` objects exist. The CNO patches `servicemonitor` and `prometheusrules` objects in the `monitoring.coreos.com` API group, which corrects the monitoring issues. (link:https://issues.redhat.com/browse/OCPBUGS-54698[OCPBUGS-54698])
Original: * Before this update, when you passed a parameter value to a pipeline or task and the value included more than one variable with both full and short reference formats, for example, `$(tasks.task-name.results.variable1) + $(variable2)`, {pipelines-shortname} did not interpret the value correctly. The pipeline run or task run could stop execution and the Pipelines controller could crash. With this update, {pipelines-shortname} interprets the value correctly and the pipeline run or task run completes.
Revised: * Before this update, when you passed a parameter value to a pipeline or task and the value included more than one variable with both full and short reference formats, for example, `$(tasks.task-name.results.variable1) + $(variable2)`, {pipelines-shortname} did not interpret the value correctly. The pipeline run or task run could stop execution and the Pipelines controller could fail. With this update, {pipelines-shortname} interprets the value correctly and the pipeline run or task run completes.
Original: The default `install-config.yaml` file configuration from the previous release of {product-title} is deprecated. Though you can still use it, the openshift-installer will display a warning message that indicates the use of deprecated fields in the configuration file.
Revised: The default `install-config.yaml` file configuration from the previous release of {product-title} is deprecated. Though you can still use it, the {product-title} installer displays a warning message that indicates the use of deprecated fields in the configuration file.
Original: The example uses the `govc` command. This open-source tool is available from VMware, not Red Hat, and is not maintained by the Red Hat support team. Instructions for downloading and installing it are found on the VMware documentation website.
Revised: The example uses the `govc` command. This open-source tool is available from VMware, not Red{nbsp}Hat, and is not maintained by the Red{nbsp}Hat support team. Instructions for downloading and installing it are found on the VMware documentation website.
Original: * Failure domain: Specifies the relationships between regions/zones in {product-title} and clusters/host groups in vSphere. You define a failure domain by using vCenter objects, such as a `datastore` object. A failure domain defines the vCenter location for {product-title} cluster nodes.
Revised: * Failure domain: Specifies the relationships between regions and zones in {product-title} and clusters and host groups in vSphere. You define a failure domain by using vCenter objects, such as a `datastore` object. A failure domain defines the vCenter location for {product-title} cluster nodes.
Original: The default `install-config.yaml` file configuration from the previous release of {product-title} is deprecated. Though you can still use it, the {product-title} installer will display a warning message that indicates the use of deprecated fields in the configuration file.
Revised: The default `install-config.yaml` file configuration from previous releases of {product-title} is deprecated. Though you can still use it, the {product-title} installer will display a warning message that indicates the use of deprecated fields in the configuration file.
Original: . To create a region tag for the vSphere cluster where you want to deploy your {product-title} cluster, enter the following command in your terminal:
Revised: . Create a region tag for the vSphere cluster where you want to deploy your {product-title} cluster by entering the following command in your terminal:
. Optional: Create a region tag for the vSphere cluster where you want to deploy your {product-title} cluster by entering the following command in your terminal:
Original: The default `install-config.yaml` file configuration previous releases of {product-title} is deprecated. Though you can still use it, the {product-title} installer will display a warning message that indicates the use of deprecated fields in the configuration file.
Revised: The default `install-config.yaml` file configuration from previous releases of {product-title} is deprecated. Though you can still use it, the {product-title} installer will display a warning message that indicates the use of deprecated fields in the configuration file.
Original: This documentation details the Red Hat responsibilities for the {product-title} managed service.
A Red Hat Site Reliability Engineer (SRE) maintains a centralized monitoring and alerting system for all {product-title} cluster components, SRE services, and underlying cloud provider accounts. Platform audit logs are securely forwarded to a centralized SIEM (Security Information and Event Monitoring) system, where they might trigger configured alerts to the SRE team and are also subject to manual review. Audit logs are retained in the SIEM for one year. Audit logs for a given cluster are not deleted at the time the cluster is deleted.
An incident is an event that results in a degradation or outage of one or more Red Hat services. An incident can be raised by a customer or Customer Experience and Engagement (CEE) member through a support case, directly by the centralized monitoring and alerting system, or directly by a member of the SRE team.
The general workflow of how a new incident is managed by Red Hat:
. The incident is recovered.
. The incident is documented and a root cause analysis is performed within 5 business days of the incident.
. A root cause analysis (RCA) draft document is shared with the customer within 7 business days of the incident.
Revised: To obtain additional information not included in the support ticket, customers can request the following workflow