gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: . Click *Actions* and select the intended action from the menu.
+
Alternatively, change the state of all VMs in a project by right-clicking the project in the tree view and selecting the intended command from the pop-up menu.
Revised: . To change the state of the all the VMs in a project, do any of the following tasks:
** Click *Actions*, and then on the pop-up menu, select the intended action.
** In the tree view, right-click the project, and then on the pop-up menu, select the intended action.
Original: . Click the *Snapshots* tab and then click *Take Snapshot*.
+
Alternatively, right-click the VM and select *Create snapshot* from the pop-up menu.
Revised: . To take a snapshot, do any of the following tasks:
** Click the *Snapshots* tab, and then click *Take Snapshot*.
** Right-click the VM, and then on the pop-up menu, click *Create snapshot*.
Original: . Click the *Actions* menu {kebab} beside a VM and select *Delete*.
Revised: . To delete a VM, do any of the following tasks:
** Click the options menu icon {kebab} beside a VM, and then click *Delete*.
** To open the *VirtualMachine details* page, click the name of the VM, and then click *Actions* -> *Delete*.
** In the tree view, right-click the VM, and then on the pop-up menu, click *Delete*.
Original: . Click the Options menu {kebab} beside the virtual machine and select *Migration* -> *Storage*.
+
You can also access this option from the *VirtualMachine details* page by selecting *Actions* -> *Migration* -> *Storage*.
+
Alternatively, right-click the VM in the tree view and select *Migration* from the pop-up menu.
Revised: . In the web console, click  *Virtualization* -> *VirtualMachines* to do any of the following tasks:
** Click the options menu icon {kebab} beside the VM, and then click *Migration* -> *Storage*.
** In the *VirtualMachine details* page, click *Actions* -> *Migration* -> *Storage*.
** In the tree view, right-click the VM, and then on the pop-up menu, click *Migration* -> *Storage*.
Original: [TIP]
====
You can copy the `virtctl ssh` command in the web console by selecting *Copy SSH command* from the options {kebab} menu beside a VM on the *VirtualMachines* page.

Alternatively, right-click the VM in the tree view and select *Copy SSH command* from the pop-up menu to copy the `virtctl ssh` command.
====
Revised: To copy the `virtctl ssh` command, in the web console, click  *Virtualization* -> *VirtualMachines* to do any of the following tasks:
** In the *VirtualMachines* page, click the options menu icon {kebab} beside a VM, and then click *Copy SSH command*.
** In the tree view, right-click the VM, and then on the pop-up menu, click *Copy SSH command* .
Original: link:https://security.access.redhat.com/data/csaf/v2/vex/[Red{nbsp}Hat VEX]:: Used with release 4.6 and later. This source provides vulnerability data in link:https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#45-profile-5-vex[Vulnerability Exploitability eXchange(VEX)] format. {product-title-short} takes advantage of VEX benefits to significantly decrease the time needed for the initial loading of vulnerability data, and the space needed to store vulnerability data.
Revised: For containers from the Red Hat Ecosystem Catalog, {product-title-short} provides an option to show only vulnerabilities from VEX data. VEX data for Red{nbsp}Hat images is the most accurate because vulnerabilities in those images have been vetted by the Red{nbsp}Hat security team and the results reported in VEX. Other vulnerability sources such as OSV can report vulnerabilities that Red Hat has determined are not applicable to the image. This can cause false positives in vulnerability results. Red{nbsp}Hat also uses VEX to provide link:https://access.redhat.com/security/middleware_security_scanning_problem[accurate security data for Middleware products].
Original: link:https://security.access.redhat.com/data/csaf/v2/vex/[Red{nbsp}Hat VEX]:: Used with release 4.6 and later. This source provides vulnerability data in link:https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#45-profile-5-vex[Vulnerability Exploitability eXchange(VEX)] format. {product-title-short} takes advantage of VEX benefits to significantly decrease the time needed for the initial loading of vulnerability data, and the space needed to store vulnerability data.
Revised: The option to use VEX data for Red{nbsp}Hat containers is disabled by default. To enable this option, in Scanner V4 Matcher, set the environment variable `ROX_SCANNER_V4_RED_HAT_LAYERS_RED_HAT_VULNS_ONLY` to `true`. Be aware that in rare instances, using this option can cause valid vulnerabilities to not appear in scan results. For example, Red{nbsp}Hat does not track vulnerabilities for products that have reached end of life.
Original: link:https://security.access.redhat.com/data/csaf/v2/vex/[Red{nbsp}Hat VEX]:: Used with release 4.6 and later. This source provides vulnerability data in link:https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#45-profile-5-vex[Vulnerability Exploitability eXchange(VEX)] format. {product-title-short} takes advantage of VEX benefits to significantly decrease the time needed for the initial loading of vulnerability data, and the space needed to store vulnerability data.
Revised: For containers from or built on top of container from the Red Hat Ecosystem Catalog, {product-title-short} provides an option to show only vulnerabilities from Red Hat's VEX data. VEX data for Red Hat images is the most accurate because vulnerabilities in those images have been vetted by the Red Hat security team. Other vulnerability sources such as OSV can report vulnerabilities that Red Hat has determined are not applicable to the image. This can cause false positives in vulnerability results. Enabling the setting to only use VEX data for Red Hat images will minimize these false positives.
Original: link:https://security.access.redhat.com/data/csaf/v2/vex/[Red{nbsp}Hat VEX]:: Used with release 4.6 and later. This source provides vulnerability data in link:https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#45-profile-5-vex[Vulnerability Exploitability eXchange(VEX)] format. {product-title-short} takes advantage of VEX benefits to significantly decrease the time needed for the initial loading of vulnerability data, and the space needed to store vulnerability data.
Revised: The option to use VEX data for Red Hat containers is disabled by default. To enable this option, in Scanner V4 Matcher, set the environment variable `ROX_SCANNER_V4_RED_HAT_LAYERS_RED_HAT_VULNS_ONLY` to `true`. Be aware that in rare instances, using this option can cause valid vulnerabilities to not appear in scan results (false negatives). For example, Red Hat does not track vulnerabilities for products that have reached end of life. Also be aware Red Hat's VEX data is missing link:https://access.redhat.com/security/middleware_security_scanning_problem[accurate security data for many Middleware products].
Original: * Port 9094 provides access to all the Alertmanager endpoints. Granting access requires binding a user to the `monitoring-alertmanager-view` (for read-only operations) or `monitoring-alertmanager-edit` role in the `openshift-monitoring` project.
Revised: * Port 9094 provides access to all the Alertmanager endpoints. Granting access requires binding a user to the `monitoring-alertmanager-view` role (for read-only operations) or the `monitoring-alertmanager-edit` role in the `openshift-monitoring` project.
Original: Shielded VM is not supported for {product-title} on {GCP} clusters using bare metal instance types. For more information, see link:https://cloud.google.com/compute/shielded-vm/docs/shielded-vm#limitations[Limitations] in the Google Cloud documentation.
Revised: Shielded VM is not supported for {product-title} on {GCP} clusters using bare-metal instance types. For more information, see link:https://cloud.google.com/compute/shielded-vm/docs/shielded-vm#limitations[Limitations] in the Google Cloud documentation.
Original: {product-title} {product-version} is supported on {op-system-base-full} 8.8 and a later version of {op-system-base} 8 that is released before End of Life of {product-title} {product-version}. {product-title} {product-version} is also supported on {op-system-first} {product-version}. To understand {op-system-base} versions used by {op-system}, see link:https://access.redhat.com/articles/6907891[{op-system-base} Versions Utilized by {op-system-first} and {product-title}] (Knowledgebase article).
You must use {op-system} machines for the control plane, and you can use either {op-system} or {op-system-base} for compute machines. {op-system-base} machines are deprecated in {product-title} 4.16 and will be removed in a future release.
Revised: You must use {op-system} machines for the control plane and the compute machines. {op-system-base} machines are not available in this release.
Original: When running on {ocp-product-title} in FIPS mode, it uses the {rhel} cryptographic libraries submitted (or planned to be submitted) to NIST for FIPS validation on only the `x86_64`, `ppc64le`, and `s390X` architectures. For more information about the NIST validation program, see link:https://csrc.nist.gov/Projects/cryptographic-module-validation-program/validated-modules[Cryptographic Module Validation Program]. For the latest NIST status of the individual versions of {rhel} cryptographic libraries that have been submitted for validation, see link:https://access.redhat.com/en/compliance[Product compliance].
Revised: When running on {ocp-product-title} in FIPS mode, it uses the {rhel} cryptographic libraries submitted, (or planned to be submitted, to NIST for FIPS validation on only the `x86_64`, `ppc64le`, and `s390X` architectures. For more information about the NIST validation program, see link:https://csrc.nist.gov/Projects/cryptographic-module-validation-program/validated-modules[Cryptographic Module Validation Program] (NIST documentation). For the latest NIST status of the individual versions of {rhel} cryptographic libraries that have been submitted for validation, see link:https://access.redhat.com/en/compliance[Product compliance].
When running on {ocp-product-title} in FIPS mode, it uses the {rhel} cryptographic libraries submitted, or planned to be submitted, to NIST for FIPS validation on only the `x86_64`, `ppc64le`, and `s390X` architectures. For more information about the NIST validation program, see link:https://csrc.nist.gov/Projects/cryptographic-module-validation-program/validated-modules[Cryptographic Module Validation Program] in the NIST documentation. For the latest NIST status of the individual versions of {rhel} cryptographic libraries that have been submitted for validation, see link:https://access.redhat.com/en/compliance[Product compliance].
Original: * The following `spec.featureGates` in the HyperConverged custom resource (CR) were moved to a new location under the `spec` field. The old fields under `spec.featureGates` are deprecated and ignored.
Revised: * The following fields in the `spec.featureGates` field in the HyperConverged custom resource (CR) were moved to a new location under the `spec` field. The old fields under `spec.featureGates` are deprecated and ignored.
Original: * The following three HyperConverged custom resource (CR) fields have been deprecated and copied from their original location under the `spec.featureGates` fields to a new location in the `spec` field, where they may be used if needed:
Revised: * The following `HyperConverged` custom resource (CR) fields have been deprecated and copied from their original location under the `spec.featureGates` fields to a new location in the `spec` field, where they can be used if needed:
Original: If any of the machine sets for which you want to enable updated boot images uses a `*-user-data` secret that is based on Ignition version 2.2.0, the Machine Config Operator converts the Ignition version to 3.4.0 when you enable updated boot images. {product-title} versions 4.5 and lower use Ignition version 2.2.0. If this conversion fails, the MCO or your cluster could degrade. An error message that includes _err: converting ignition stub failed: failed to parse Ignition config_ is added to the output of the `oc get ClusterOperator machine-config` command. You can use the following general steps to correct the problem:
Revised: If any of the machine sets for which you want to enable boot image management use a `*-user-data` secret that is based on Ignition version 2.2.0, the Machine Config Operator converts the Ignition version to 3.4.0 when you enable the feature. {product-title} versions 4.5 and lower use Ignition version 2.2.0. If this conversion fails, the MCO or your cluster could degrade. An error message that includes _err: converting ignition stub failed: failed to parse Ignition config_ is added to the output of the `oc get ClusterOperator machine-config` command. You can use the following general steps to correct the problem:
Original: <1> Configures the boot image update feature.
<4> Specifies that the default behavior is disabled for specific machine sets.
<5> Specifies that the default behavior is enabled for only machine sets with these labels. The behavior is disabled for any machine set that does not contain the listed labels.
Revised: <5> Specifies that the feature is enabled only for machine sets with these labels. The feature is disabled for any machine set that does not contain the listed labels.
Original: = About updated boot images
For {gcp-short} and {aws-short}, you can disable this default behavior, if needed. When disabled, the boot image no longer updates with the cluster. For example, with the default behavior disabled, if your cluster was originally created with {product-title} 4.16, the boot image that the MCO would use to create nodes is the same 4.16 version, even if your cluster is at a later version.
Revised: For {gcp-short} and {aws-short}, you can disable the boot image management feature, if needed. When the feature is disabled, the boot image no longer updates with the cluster. For example, with the feature disabled, if your cluster was originally created with {product-title} 4.16, the boot image that the MCO would use to create nodes is the same 4.16 version, even if your cluster is at a later version.
Original: |Whether to use Confidential VMs for all machines in the cluster. Confidential VMs provide encryption for data during processing. For more information on Confidential computing, see Google's documentation on link:https://cloud.google.com/confidential-computing[Confidential computing].
|`Enabled` or `Disabled`. The default value is `Disabled`.
Revised: |Whether to use Confidential VMs for all machines in the cluster. Confidential VMs provide encryption for data during processing. For more information on Confidential computing, see Google's documentation about link:https://cloud.google.com/confidential-computing[Confidential Computing].
Original: |Whether to enable Confidential VMs for control plane machines. Confidential VMs provide encryption for data while it is being processed. For more information on Confidential VMs, see Google's documentation on link:https://cloud.google.com/confidential-computing[Confidential Computing].
|`Enabled` or `Disabled`. The default value is `Disabled`.
Revised: |Whether to use Confidential VMs for control plane machines. Confidential VMs provide encryption for data during processing. For more information on Confidential Computing, see Google's documentation about link:https://cloud.google.com/confidential-computing[Confidential computing].
Original: |Whether to enable Confidential VMs for control plane machines. Confidential VMs provide encryption for data while it is being processed. For more information on Confidential VMs, see Google's documentation on link:https://cloud.google.com/confidential-computing[Confidential Computing].
|`Enabled` or `Disabled`. The default value is `Disabled`.
Revised: If you specify any value other than `Disabled`, you must set `controlPlane.platform.gcp.defaultMachinePlatform.onHostMaintenance` to `Terminate`.
Original: |Whether to enable Confidential VMs for compute machines. Confidential VMs provide encryption for data while it is being processed. For more information on Confidential VMs, see Google's documentation on link:https://cloud.google.com/confidential-computing[Confidential Computing].
|`Enabled` or `Disabled`. The default value is `Disabled`.
Revised: If you specify any value other than `Disabled`, you must set `compute.platform.gcp.onHostMaintenance` to `Terminate`.
Original: === Operator lifecycle
Revised: You can enable port isolation for a Linux bridge network attachment definition (NAD) so that virtual machines (VMs) or pods that run on the same virtual LAN (VLAN) can operate in isolation from one another. For more information, see xref:../virt/vm_networking/virt-connecting-vm-to-linux-bridge.adoc#virt-linux-bridge-nad-port-isolation_virt-connecting-vm-to-linux-bridge[Connecting a virtual machine to a Linux bridge network].
Original: * When using the BYO Knowledge tool to create a retrieval-augmented generation (RAG) database, you must create `OLSConfig` custom resource file with BYO Knowledge index before you create the {ocp-product-title} index.
Revised: * When using the BYO Knowledge tool to create a retrieval-augmented generation (RAG) database, you must create a `OLSConfig` custom resource file with BYO Knowledge index before you create the {ocp-product-title} index.
Original: * This release makes {ols-official} 1.0 generally available, adds new features, addresses Common Vulnerabilities and Exposures (CVEs), and is supported on {ocp-product-title} OpenShift Container Platform 4.15 and later.
Revised: * This release makes {ols-official} 1.0 generally available, adds new features, addresses Common Vulnerabilities and Exposures (CVEs), and is supported on {ocp-product-title} 4.15 and later.
Original: * Direct navigation to individual incident detail is now supported in the troubleshooting panel, and this enables the incidents overview functionality in {rh-rhacm-first} 2.14. (link:https://issues.redhat.com/browse/COO-977[*COO-977*], link:https://issues.redhat.com/browse/ACM-18751[*ACM-18751*])
Revised: * Direct navigation to individual incident detail is now supported in the incident detection panel, and this enables the incidents overview functionality in {rh-rhacm-first} 2.14. (link:https://issues.redhat.com/browse/COO-977[*COO-977*], link:https://issues.redhat.com/browse/ACM-18751[*ACM-18751*])
Original: * Accelerators Perses dashboards are deployed by default when you install the dashboard UI plugin. (link:https://issues.redhat.com/browse/COO-942[*COO-942*]) 
Revised: * Accelerator Perses dashboards are deployed by default when you install the dashboard UI plugin. (link:https://issues.redhat.com/browse/COO-942[*COO-942*])
Original: * The status of the distributed tracing UI plugin is now General Avaiability (GA), supporting Patternfly 4, 5 and 6. (link:https://issues.redhat.com/browse/COO-873[*COO-873*]) 
Revised: * The status of the distributed tracing UI plugin is now General Availability (GA), supporting Patternfly 4, 5 and 6. (link:https://issues.redhat.com/browse/COO-873[*COO-873*])
Original: ----
Revised: * Verify that the SPIFFE Container Storage Interface (CSI) Driver pods are running by running the following command:
* Verify that the daemonset of the SPIFFE CSI driver is ready and available by running the following command


[source,terminal]
$ oc get daemonset -l app.kubernetes.io/name=spiffe-csi-driver -n zero-trust-workload-identity-manager

.Example output
[source,terminal]
NAME                      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
spire-spiffe-csi-driver   3         3         3       3            3           <none>          114s
Original: <5> The type of verification to be done against kubelet. Valid options are `auto`, `hostCert`, `apiServerCA`, `skip`. `auto` initially attempts to use `hostCert`, and then falls back to `apiServerCA`.
Revised: <5> The type of verification to be done against kubelet. Valid options are `auto`, `hostCert`, `apiServerCA`, `skip`. The `auto` option initially attempts to use `hostCert`, and then falls back to `apiServerCA`.
Original: .Verify

A secondary interface is automatically part of the UDN when you add a pod into the namespace.

. Confirm the secondary interface is part of the UDN by running the following commands:
+
[source,terminal]
----
$ oc project 49ers
pod=$(oc get --no-headers pods | awk '{ print $1;}') <1>
----
+
[source,terminal]
----
$ oc describe pod/$pod  <2>
----
<1> Get pod name.
<2> Two interfaces are mentioned in *Annotations*.

All pods in this namespace are isolated from pods in other namespaces. In essence, a namespace can be a tenant.
Revised: .Verification

When you refresh the *Network Traffic* page, the *Traffic Flow* and *Topology* views display new information about UDNs:

1. In *Network Traffic* > *Traffic flows*, UDNs are viewable under the SrcK8S_NetworkName and DstK8S_NetworkName fields.
2. In the *Topology* view, you can set *Network* as *Scope* or *Group*.
Original: User-defined networks (UDN) improve the flexibility and segmentation capabilities of the default Layer 3 topology for a Kubernetes pod network by enabling custom Layer 2 and Layer 3 network segments, where all these segments are isolated by default. These segments act as either primary or secondary networks for container pods and virtual machines that use the default OVN-Kubernetes CNI plugin.
Revised: User-defined networks (UDN) improve the flexibility and segmentation capabilities of the default Layer 3 topology for a Kubernetes pod network by enabling custom Layer 2 and Layer 3 network segments, where all these segments are isolated by default. These segments act as primary or secondary networks for container pods and virtual machines that use the default OVN-Kubernetes CNI plugin.
Original: Refresh the *Network Traffic* page to view updated UDN information in the *Traffic Flow* and *Topology* views:

. In *Network Traffic* > *Traffic flows*, you can view UDNs under the `SrcK8S_NetworkName` and `DstK8S_NetworkName` fields.
. In the *Topology* view, you can set *Network* as *Scope* or *Group*.
Revised: * Refresh the *Network Traffic* page to view updated UDN information in the *Traffic Flow* and *Topology* views:

** In *Network Traffic* > *Traffic flows*, you can view UDNs under the `SrcK8S_NetworkName` and `DstK8S_NetworkName` fields.
** In the *Topology* view, you can set *Network* as *Scope* or *Group*.
Original: config:
processors:
cumulativetodelta:
include: # <1>
match_type: strict # <2>
metrics: # <3>
- <metric_1_name>
- <metric_2_name>
exclude: # <4>
match_type: regexp
metrics:
- "<regular_expression_for_metric_names>"
# ...
----
<1> Optional: Configures which metrics to include. When omitted, all metrics, except for those listed in the `exclude` field, are converted to delta metrics.
<2> Defines a value provided in the `metrics` field as a `strict` exact match or `regexp` regular expression.
<3> Lists the metric names, which are exact matches or matches for regular expressions, of the metrics to be converted to delta metrics. If a metric matches both the `include` and `exclude` filters, the `exclude` filter takes precedence.
<4> Optional: Configures which metrics to exclude. When omitted, no metrics are excluded from conversion to delta metrics.
Revised: <1> This processor requires a stateful Collector deployment. Deploy it as a sidecar to the application that emits the delta temporality metrics.