gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: * Cluster workload information transformed into discreet Secure Hash Algorithm (SHA) values, which allows Red Hat to assess workloads for security and version vulnerabilities without disclosing sensitive details.
* Workload information about the operating system and runtime environment, including runtime kinds, names, and versions, which you can optionally enable through the `InsightsRuntimeExtractor` feature gate. This data gives Red Hat a better understanding of how you use {product-title} containers so that we can proactively help you make investment decisions to drive optimal utilization.
+
--
:FeatureName: InsightsRuntimeExtractor
include::snippets/technology-preview.adoc[]
--
Revised: * Cluster workload information transformed into discreet Secure Hash Algorithm (SHA) values, which allows Red{nbsp}Hat to assess workloads for security and version vulnerabilities without disclosing sensitive details.
Original: * Cluster workload information transformed into discreet Secure Hash Algorithm (SHA) values, which allows Red Hat to assess workloads for security and version vulnerabilities without disclosing sensitive details.
* Workload information about the operating system and runtime environment, including runtime kinds, names, and versions, which you can optionally enable through the `InsightsRuntimeExtractor` feature gate. This data gives Red Hat a better understanding of how you use {product-title} containers so that we can proactively help you make investment decisions to drive optimal utilization.
+
--
:FeatureName: InsightsRuntimeExtractor
include::snippets/technology-preview.adoc[]
--
Revised: * Workload information about the operating system and runtime environment, including runtime kinds, names, and version. This data gives Red{nbsp}Hat a better understanding of how you use {product-title} containers so that we can proactively help you make investment decisions to drive optimal utilization.
Original: * It is now possible to filter workflow instances by the content of workflow variables using GraphQL queries on `ProcessInstances.variables`. For example, the following query retrieves process instances where the `language` field in `workflowdata` equals `Spanish`:
Revised: * You can now filter workflow instances by the content of workflow variables using GraphQL queries on `ProcessInstances.variables`. For example, the following query retrieves process instances where the `language` field in `workflowdata` equals `Spanish`:
Original: * Transport encryption for Knative Eventing is now available as a Generally Available (GA) feature. Eventing components can be configured to secure in-transit data by exposing HTTPS addresses and trusting user-provided CA trust bundles.
Revised: * Transport encryption for Knative Eventing is now available as a Generally Available (GA) feature. You can configure Eventing components to secure in-transit data by exposing HTTPS addresses and trusting user-provided CA trust bundles.
Original: * {ServerlessLogicProductName} Data Index now supports filtering queries using workflow definition metadata. Additionally, Data Index has been updated to consume deploy and undeploy events, improving the accuracy and traceability of workflow state. 
Revised: * {ServerlessLogicProductName} Data Index now supports filtering queries by using workflow definition metadata. Additionally, Data Index has been updated to consume deploy and undeploy events, improving the accuracy and traceability of workflow state.
Original: * When deploying a workflow in the `preview` profile on {ocp-product-title}, if the initial build fails and is later corrected, the Operator does not create the corresponding workflow deployment. As a result, the deployment remains missing and the SonataFlow status is not updated, even after the build is fixed.
Revised: * When deploying a workflow in the `preview` profile on {ocp-product-title}, if the initial build fails and is later corrected, the Operator does not create the corresponding workflow deployment. As a result, the deployment remains missing and the `SonataFlow` status is not updated, even after the build is fixed.
Original: * Images used by the {ServerlessLogicProductName} web tools are tagged with the product version `1.36.0`, even though they are built in midstream and do not exactly match the content of the official {ServerlessLogicProductName} product build. This discrepancy may cause confusion and lead to unexpected issues if you rely on version consistency. Additionally, you might expect that version `1.36.0` of the web tools is based on `9.103.0.redhat-00004` of the Kogito artifacts. However, this is not accurate for the web tools.
Revised: * Images used by the {ServerlessLogicProductName} web tools are tagged with the product version `1.36.0`, even though they are built in midstream and do not exactly match the content of the official {ServerlessLogicProductName} product build. This might cause confusion and lead to unexpected issues if you rely on version consistency. Additionally, you might expect that version `1.36.0` of the web tools is based on `9.103.0.redhat-00004` of the Kogito artifacts. However, this is not accurate for the web tools.
Original: * {ServerlessProductName} Eventing introduces EventTransform, a new API resource that allows you to declaratively transform JSON events without writing custom code. With EventTransform, you can modify attributes, extract or reshape data, and streamline event flows across systems. Common use cases include event enrichment, format conversion, and request-response transformation. EventTransform integrates seamlessly with Knative sources, triggers, and brokers, enhancing interoperability in event-driven architectures.
Revised: * {ServerlessProductName} Eventing introduces EventTransform, a new API resource that you can use to declaratively transform JSON events without writing custom code. With EventTransform, you can modify attributes, extract or reshape data, and streamline event flows across systems. Common use cases include event enrichment, format conversion, and request-response transformation. EventTransform integrates seamlessly with Knative sources, triggers, and brokers, enhancing interoperability in event-driven architectures.
Original: * The `openshift-serverless-1/logic-swf-builder-rhel8:1.35.0` image currently downloads persistence extensions from Maven during the build process. 
Revised: * The `openshift-serverless-1/logic-swf-builder-rhel8:1.35.0` and `openshift-serverless-1/logic-swf-builder-rhel8:1.36.0` images currently downloads persistence extensions from Maven during the build process.
Original: * `IntegrationSource` and `IntegrationSink` are now available as a Technology Preview. These are Knative Eventing custom resources that support selected Kamelets from the Apache Camel project. Kamelets enables you to connect to third-party systems for improved connectivity, acting as either sources (event producers) or sinks (event consumers).
Revised: * `IntegrationSource` and `IntegrationSink` are now available as a Technology Preview. These are Knative Eventing custom resources that support selected Kamelets from the Apache Camel project. Kamelets enable you to connect to third-party systems for improved connectivity, acting as either sources (event producers) or sinks (event consumers).
Original: * Knative Eventing can now automatically discover and register EventTypes based on the structure of incoming events. This feature simplifies the configuration and management of EventTypes, reducing the need for manual definitions. This feature is available as a Technology Preview.
Revised: * Knative Eventing can now automatically discover and register `EventTypes` objects based on the structure of incoming events. This feature simplifies the configuration and management of event types, reducing the need for manual definitions. This feature is available as a Technology Preview.
Original: * {ServerlessProductName} Eventing introduces `EventTransform`, a new API resource that you can use to declaratively transform JSON events without writing custom code. With `EventTransform`, you can modify attributes, extract or reshape data, and streamline event flows across systems. Common use cases include event enrichment, format conversion, and request-response transformation. `EventTransform` integrates seamlessly with Knative sources, triggers, and brokers, enhancing interoperability in event-driven architectures. This feature is now available as a Technology Preview.
Revised: * {ServerlessProductName} Eventing introduces `EventTransform` objects, a new API resource that you can use to declaratively transform JSON events without writing custom code. With `EventTransform` objects, you can modify attributes, extract or reshape data, and streamline event flows across systems. Common use cases include event enrichment, format conversion, and request-response transformation. Event transformations integrate seamlessly with Knative sources, triggers, and brokers, enhancing interoperability in event-driven architectures. This feature is now available as a Technology Preview.
Original: ** Define transformations declaratively using Kubernetes-native resources
** Use JSONata expressions for advanced and flexible event data manipulation
** Easily insert transformations at any point within event-driven workflows
** Support for transforming both sink-bound and reply events for better routing control
Revised: ** Define transformations declaratively using Kubernetes-native resources.
** Use JSONata expressions for advanced and flexible event data manipulation.
** Easily insert transformations at any point within event-driven workflows.
** Transform both sink-bound and reply events for better routing control.
Original: [id="virt-4-18-ki-nodes"]
=== Nodes
[id="virt-4-18-ki-storage"]
=== Storage

[id="virt-4-18-ki-virtualization"]
=== Virtualization
[discrete]
[id="virt-4-16-ki-webconsole_{context}"]
=== Web console
[id="virt-4-18-ki-ibm-z_{context}"]
Revised: * In the {product-title} web console, it is erroneously possible to define multiple CPU threads for a VM based on s390x architecture. If you define multiple CPU threads, the VM enters a `CrashLoopBackOff` state with the `qemu-kvm: S390 does not support more than 1 threads` error . (link:https://issues.redhat.com/browse/CNV-56890[CNV-56890])
Original: [id="virt-4-18-ki-nodes"]
=== Nodes
[id="virt-4-18-ki-storage"]
=== Storage

[id="virt-4-18-ki-virtualization"]
=== Virtualization
[discrete]
[id="virt-4-16-ki-webconsole_{context}"]
=== Web console
[id="virt-4-18-ki-ibm-z_{context}"]
Revised: * In the {product-title} web console, the *Boot mode* list for an s390x VM incorrectly includes *BIOS*, *UEFI*, and *UEFI (secure)* boot modes. If you select one of these modes for an s390x-based VM, the operation fails. This is because VMs based on s390x architecture can only use the *IPL* boot mode. (link:https://issues.redhat.com/browse/CNV-56889[CNV-56889])
Original: * You can now flatten the virtual machine (VM) definition file when creating a VM using instance types and preferences. For more information, see link:https://access.redhat.com/solutions/7107803[Using InstancetypeReferencePolicy to expand VirtualMachines] in the Red Hat Customer Portal.
Revised: * You can now optionally expand virtual machines (VMs) when using instance types and preferences. For more information, see link:https://access.redhat.com/solutions/7107803[Using InstancetypeReferencePolicy to expand VirtualMachines] in the Red Hat Customer Portal.
Original: {product-title} validating webhooks are a set of dynamic admission controls maintained by the OpenShift SRE team. These HTTP callbacks, also known as webhooks, are called for various types of requests to ensure cluster stability. The following list describes the various webhooks with rules containing the registered operations and resources that are controlled. Any attempt to circumvent these validating webhooks could affect the stability and supportability of the cluster.
Revised: {product-title} validating webhooks are a set of dynamic admission controls maintained by the OpenShift SRE team. These HTTP callbacks, also known as webhooks, are called for various types of requests to ensure cluster stability. The webhooks evaluate each request and either accept or reject it. The following list describes the various webhooks with rules containing the registered operations and resources that are controlled. Any attempt to circumvent these validating webhooks could affect the stability and supportability of the cluster.
Original: * Full `must-gather` data collection, including Prometheus metrics:
The data is saved as `must-gather/must-gather.tar.gz`. You can upload this file to a support case on the link:https://access.redhat.com/[Red Hat Customer Portal].

* Essential `must-gather` data collection, without Prometheus metrics, for a specific time duration:
$ oc adm must-gather --image={must-gather-v1-3} \
-- /usr/bin/gather_<time>_essential <1>
<1> Specify the time in hours. Allowed values are `1h`, `6h`, `24h`, `72h`, or `all`, for example, `gather_1h_essential` or `gather_all_essential`.

* `must-gather` data collection with timeout:
$ oc adm must-gather --image={must-gather-v1-3} \
-- /usr/bin/gather_with_timeout <timeout> <1>
<1> Specify a timeout value in seconds.

* Prometheus metrics data dump:
Revised: * To use a combination of the insecure TLS connection and the timeout flags with the `must-gather` tool, run the following command:
Original: * Full `must-gather` data collection, including Prometheus metrics:
The data is saved as `must-gather/must-gather.tar.gz`. You can upload this file to a support case on the link:https://access.redhat.com/[Red Hat Customer Portal].

* Essential `must-gather` data collection, without Prometheus metrics, for a specific time duration:
$ oc adm must-gather --image={must-gather-v1-3} \
-- /usr/bin/gather_<time>_essential <1>
<1> Specify the time in hours. Allowed values are `1h`, `6h`, `24h`, `72h`, or `all`, for example, `gather_1h_essential` or `gather_all_essential`.

* `must-gather` data collection with timeout:
$ oc adm must-gather --image={must-gather-v1-3} \
-- /usr/bin/gather_with_timeout <timeout> <1>
<1> Specify a timeout value in seconds.

* Prometheus metrics data dump:
$ oc adm must-gather --image={must-gather-v1-3} -- /usr/bin/gather_metrics_dump
This operation can take a long time. The data is saved as `must-gather/metrics/prom_data.tar.gz`.
Original: You can use the Insights for OpenShift advisor service to view and manage information about recommendations that affect not only your clusters, but also your workloads. Insights advisor takes advantage of deployment validation and allows OpenShift cluster administrators to see all runtime violations of deployment policies. You can see recommendations for workloads at link:https://console.redhat.com/openshift/insights/advisor/workloads[OpenShift > Advisor > Workloads] on the {hybrid-console}. For more information, see these additional resources:
Revised: You can use the Insights for OpenShift advisor service to view and manage information about recommendations that affect not only your clusters, but also your workloads. Insights advisor takes advantage of deployment validation and helps OpenShift cluster administrators to see all runtime violations of deployment policies. You can see recommendations for workloads at link:https://console.redhat.com/openshift/insights/advisor/workloads[OpenShift > Advisor > Workloads] on the {hybrid-console}. For more information, see these additional resources:
Original: Using cluster data collected by the Insights Operator, Insights repeatedly compares that data against a library of _recommendations_. Each recommendation is a set of cluster-environment conditions that can leave {product-title} clusters at risk. The results of the Insights analysis are available in the Insights Advisor service on Red Hat Hybrid Cloud Console. In the Console, you can perform the following actions:
Revised: If the cluster has the Deployment Validation Operator installed, the recommendations also highlight workloads whose configuration might lead to cluster health issues.
Original: Using cluster data collected by the Insights Operator, Insights repeatedly compares that data against a library of _recommendations_. Each recommendation is a set of cluster-environment conditions that can leave {product-title} clusters at risk. The results of the Insights analysis are available in the Insights Advisor service on Red Hat Hybrid Cloud Console. In the Console, you can perform the following actions:
* See clusters impacted by a specific recommendation.
Revised: * View clusters and workloads affected by specific recommendations.
Original: Insights repeatedly analyzes the data Insights Operator sends. Users of {product-title} can display the report in the {insights-advisor-url} service on {hybrid-console}.
Revised: Insights repeatedly analyzes the data Insights Operator sends, which includes workload recommendations from Deployment Validation Operator (DVO). Users of {product-title} can display the results in the {insights-advisor-url}. The users of {product-title} can display the results in the {insights-advisor-url} service on {hybrid-console}.
Original: You can use the Red Hat Insights for OpenShift advisor service to view and manage information about recommendations that affect not only your clusters, but also your workloads. The advisor service takes advantage of deployment validation and helps OpenShift cluster administrators to see all runtime violations of deployment policies. You can see recommendations for workloads at link:https://console.redhat.com/openshift/insights/advisor/workloads[OpenShift > Advisor > Workloads] on the {hybrid-console}. For more information, see these additional resources:
Revised: You can use the Red Hat Insights for OpenShift advisor service to view and manage information about recommendations that affect not only your clusters, but also your workloads. The advisor service takes advantage of deployment validation and helps {product-title} cluster administrators to see all runtime violations of deployment policies. You can see recommendations for workloads at link:https://console.redhat.com/openshift/insights/advisor/workloads[OpenShift > Advisor > Workloads] on the {hybrid-console}. For more information, see these additional resources:
Original: You can use Insights Advisor to assess and monitor the health of your {product-title} clusters. Whether you are concerned about individual clusters, or with your whole infrastructure, it is important to be aware of the exposure of your cluster infrastructure to issues that can affect service availability, fault tolerance, performance, or security.
Using cluster data collected by the Insights Operator, Insights repeatedly compares that data against a library of _recommendations_. Each recommendation is a set of cluster-environment conditions that can leave {product-title} clusters at risk. The results of the Insights analysis are available in the Insights Advisor service on Red Hat Hybrid Cloud Console. In the Console, you can perform the following actions:
Revised: If the cluster has the Deployment Validation Operator (DVO) installed, the recommendations also highlight workloads whose configuration might lead to cluster health issues.
Original: While the Egress IPs capability manages the IP address capacity per node, it is important to plan for this constraint in your deployments. For example, for a cluster installed on bare-metal infrastructure with 8 nodes you can configure 150 egress IP addresses. However, if a public cloud provider limits IP address capacity to 10 IP addresses per node, the total number of assignable IP addresses is only 80. To achieve the same IP address capacity in this example cloud provider, you would need to allocate 7 additional nodes.
Revised: While the Egress IPs capability manages the IP address capacity per node, it is important to plan for this constraint in your deployments. For example, if a public cloud provider limits IP address capacity to 10 IP addresses per node, for a cluster with 8 nodes, the total number of assignable IP addresses is only 80. To increase this to 150 IP addresses per node, you must allocate 7 additional nodes.
Original: |Configures the value that `claim` must have when taken from the incoming JWT claims. If the value in the JWT claims does not match, the token will be rejected for authentication. Must not be an empty string (`""`).
Revised: |Configures the value that `claim` must have when taken from the incoming JWT claims. If the value in the JWT claims does not match, the token is rejected for authentication. Must not be an empty string (`""`).
Original: When specified, it references a secret in the `openshift-config` namespace that contains the client secret in the `clientSecret` key of the `.data` field. The client secret will be used when making authentication requests to the identity provider.
Revised: When specified, it references a secret in the `openshift-config` namespace that contains the client secret in the `clientSecret` key of the `.data` field. The client secret is used when making authentication requests to the identity provider.
Original: After switching to direct authentication, existing authentication configuration is not guaranteed to remain unchanged. Prior to enabling direct authentication, back up any existing user, group, or identity provider configuration in case you need to revert back to using the built-in OAuth server for authentication.
Revised: After switching to direct authentication, existing authentication configuration is not guaranteed to remain unchanged. Prior to enabling direct authentication, back up any existing user, group, oauthclient or identity provider configuration in case you need to revert back to using the built-in OAuth server for authentication.
Original: * Before this update, the pipeline controller could stop working when a matrix task had no `TaskRun` CR to execute. With this update, the pipeline controller performs validation of a matrix task, and when the a `TaskRun` CR is not present, the resulting `ResolvedTask` task is nil and the controller performs no further validation.
Revised: * Before this update, the pipeline controller could stop working when a matrix task had no `TaskRun` CR to execute. With this update, the pipeline controller performs validation of a matrix task, and when the `TaskRun` CR is not present, the resulting `ResolvedTask` task is nil and the controller performs no further validation.
Original: * Before this update, the pipeline controller could stop working when a matrix task had no `TaskRun` CR to execute. With this update, the pipeline controller performs validation of a matrix task, and when the `TaskRun` CR is not present, the resulting `ResolvedTask` task is nil and the controller performs no further validation.
Revised: * Before this update, the pipeline controller could stop working when a matrix task had no `TaskRun` custom resource (CR) to execute. With this update, the pipeline controller performs validation of a matrix task, and when the `TaskRun` CR is not present, the resulting `ResolvedTask` task is nil, and the controller skips further validation.
Original: * Before this update, if you used the `buildah` task that is shipped in the `openshift-pipelines` namespace and specified an entitlement secret, {pipelines-shortname} logged a `permission denied` error. By default, the task expected `ReadWrite` permissions on all directories, however, it used the entitlement secret as a volume and this secret is mounted with `ReadOnly` permissions. With this update, the expected permissions are corrected and you can use the `buildah` task successfully without a permissions error.
Revised: * Before this update, if you used the `buildah` task shipped in the `openshift-pipelines` namespace and specified an entitlement secret, {pipelines-shortname} logged a `permission denied` error. By default, the task expected `ReadWrite` permissions on all directories. However, it used the entitlement secret as a volume, and this secret was mounted with `ReadOnly` permissions. With this update, the expected permissions are corrected, and you can use the `buildah` task successfully without a permission error.