gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: * The default value for the `disableFsBackup` parameter is `false` or `non-existing`, which is the same as false. With this, the following options are added to the `SecurityContext`:
** `Privileged: true`
** `AllowPrivilegeEscalation: true`
* With the `disableFsBackup`parameter set to `true`, removes the following mounts from the node-agent:
Revised: * The default value for the `disableFsBackup` parameter is `false` or `non-existing`. With this update, the following options are added to the `SecurityContext` field:
** `Privileged: true`
** `AllowPrivilegeEscalation: true`
* If you set the `disableFsBackup` parameter to `true`, it removes the following mounts from the node-agent:
Original: You can use the optional Velero server parameter `--item-block-worker-count`to run additional worker threads to process items in parallel. To enable this in OADP, set the `dpa.Spec.Configuration.Velero.ItemBlockWorkerCount` parameter to an integer value greater than zero.
Revised: You can use the optional Velero server parameter `--item-block-worker-count` to run additional worker threads to process items in parallel. To enable this in OADP, set the `dpa.Spec.Configuration.Velero.ItemBlockWorkerCount` parameter to an integer value greater than zero.
Original: With this release, for all the {oadp-first} Operator containers such as `operator-manager`, `velero`, `node-agent`, and `non-admin-controller`, the `terminationMessagePolicy` field can now set to the `FallbackToLogsOnError` value. This change ensures that if a container exits with an error and the termination message file is empty, {OCP-short} will use the last portion of the container's log output as the termination message.
Revised: With this release, the `terminationMessagePolicy` field can now set the `FallbackToLogsOnError` value for the {oadp-first} Operator containers such as `operator-manager`, `velero`, `node-agent`, and `non-admin-controller`. This change ensures that if a container exits with an error and the termination message file is empty, {OCP-short} uses the last portion of the container logs output as the termination message.
Original: Previously, the Namespace admin could not execute an application after the restore operation with the errors such as `exec operation is not allowed because the pod's security context exceeds your permissions`, `unable to validate against any security context constraint`, or `not usable by user or serviceaccount, provider restricted-v2`.
Revised: Previously, the namespace admin could not execute an application after the restore operation with the following errors:

* `exec operation is not allowed because the pod's security context exceeds your permissions`
* `unable to validate against any security context constraint`
* `not usable by user or serviceaccount, provider restricted-v2`
Original: Previously, status restoration was only configured at the resource type using the `restoreStatus` field in the Restore custom resource (CR). With this release, you can now specify the status restoration at the individual resource instance level using the following annotation:
Revised: Previously, status restoration was only configured at the resource type using the `restoreStatus` field in the `Restore` custom resource (CR). With this release, you can now specify the status restoration at the individual resource instance level using the following annotation:
Original: Previously, where AWS credentials using STS authentication were not properly validated. With this update, the `parseAWSSecret` function detects STS-specific fields, and updates the `ensureSecretDataExists` function to handle STS profiles correctly.
Revised: Previously, AWS credentials using STS authentication were not properly validated. With this update, the `parseAWSSecret` function detects STS-specific fields, and updates the `ensureSecretDataExists` function to handle STS profiles correctly.
Original: Previously, the new configurations for repository maintenance job pod affinity was missing from a DPA specification. With this update, the `repositoryMaintenance` job affinity config is now available to map a `BackupRepository`identifier to its configuration.
Revised: Previously, the new configurations for repository maintenance job pod affinity was missing from a DPA specification. With this update, the `repositoryMaintenance` job affinity config is now available to map a `BackupRepository` identifier to its configuration.
Original: Previously, when a restore operation was triggered with the `includedNamespace` field in a DPA specification, restore operation was completed successfully but no `VolumesnapshotContents` were created and the PVCs were in a `Pending` status.
Revised: Previously, when a restore operation was triggered with the `includedNamespace` field in a DPA specification, restore operation was completed successfully but no `VolumesnapshotContents` objects were created and the PVCs were in a `Pending` status.
Original: With this update, the `volumeSnapshotContents` are restored even when the `includedNamesapces` field is used in `restoreSpec`. As a result, an application pod is in a `Running` state after restore. 
Revised: With this update, `volumeSnapshotContents` are restored even when the `includedNamesapces` field is used in `restoreSpec`. As a result, an application pod is in a `Running` state after restore.
Original: Even after deleting a backup, Kopia does not delete the volume artifacts from the ${bucket_name}/kopia/${namespace} on the S3 location after the backup expired. To ensure that {oadp-first} functions properly, the data is not deleted, and it exists in the `/kopia/` directory, for example:
Revised: Even after deleting a backup, Kopia does not delete the volume artifacts from the `${bucket_name}/kopia/${namespace}` on the S3 location after the backup expired. To ensure that {oadp-first} functions properly, the data is not deleted, and it exists in the `/kopia/` directory, for example:
Original: .Support for HyperShift hosted OpenShift clusters is available as a Technology Preview

{oadp-short} can support and facilitate application migrations within HyperShift hosted {OCP-short} clusters as a Technology Preview. It ensures a seamless backup and restore operation for applications in HyperShift hosted clusters.
For more information about the support scope of Red Hat Technology Preview features, see link:https://access.redhat.com/support/offerings/techpreview/[Technology Preview Features Support Scope].
Revised: .Support for HyperShift hosted OpenShift clusters is available as a Technology Preview

{oadp-short} can support and facilitate application migrations within HyperShift hosted {OCP-short} clusters as a Technology Preview. It ensures a seamless backup and restore operation for applications in hosted clusters.
For more information about the support scope of Red{nbsp}Hat Technology Preview features, see link:https://access.redhat.com/support/offerings/techpreview/[Technology Preview Features Support Scope].
Original: Previously, when a restore operation was triggered with the `includedNamespace` field in a DPA specification, restore operation was completed successfully but no `volumeSnapshotContents` custom resources (CR) were created and the PVCs were in a `Pending` status.
Revised: Previously, when a restore operation was triggered with the `includedNamespace` field in a restore specification, restore operation was completed successfully but no `volumeSnapshotContents` custom resources (CR) were created and the PVCs were in a `Pending` status.
Original: With {oadp-first} 1.5.0, the `configuration.restic.podConfig.resourceAllocations` specification field has been deprecated. Use the `nodeAgent` section with the `uploaderType` field set to `Kopia` instead of `Restic`.
Revised: With {oadp-first} 1.5.0, the `configuration.restic.podConfig.resourceAllocations` specification field has been deprecated. Use the `nodeAgent` section with the `uploaderType` field for selecting kopia or restic as a uploader type. Note: Restic is deprecated in 1.5
Original: With {oadp-first} 1.5.0, the `configuration.restic.podConfig.resourceAllocations` specification field has been deprecated. Use the `nodeAgent` section with the `uploaderType` field set to `Kopia` instead of `Restic`.
Revised: With {oadp-first} 1.5.0, the `configuration.restic` specification field has been deprecated. Use the `nodeAgent` section with the `uploaderType` field set to `Kopia` instead of `Restic`.
Original: Even after deleting a backup, Kopia does not delete the volume artifacts from the `${bucket_name}/kopia/${namespace}` on the S3 location after the backup expired. To ensure that {oadp-first} functions properly, the data is not deleted, and it exists in the `/kopia/` directory, for example:
Revised: Even after deleting a backup, Kopia does not delete all the volume artifacts from the `${bucket_name}/kopia/${namespace}` on the S3 location after the backup expired. The remaining items are metadata related to the expired and purged data files. To ensure that {oadp-first} functions properly, the data is not deleted, and it exists in the `/kopia/` directory, for example:
Original: To secure an OpenAPI service operation, define a security scheme by using the OpenAPI specification. These schemes are in the `Security Scheme Object` section of the OpenAPI specification file. When a workflow invokes an operation, it uses the defined security scheme to determine the required authentication configuration.
Revised: To secure an OpenAPI service operation, define a `Security Scheme` by using the OpenAPI specification. These schemes are in the `securitySchemes` section of the OpenAPI specification file.

Finally, you must configure the operation by adding add a `Security Requirement` that refers to that `Security Scheme`.

When a workflow invokes such operation, that information is used to determine the required authentication configuration.
Original: The following property links the generator to a specific scheme from the `securitySchemes` list. The value must match the name of a scheme such as `http-basic-example` or `api-key-example`:
Revised: To configure that scheme, you must use the `quarkus.openapi-generator.codegen.default-security-scheme` property. The value must match any of the available schemes in `securitySchemes` section, such as `http-basic-example` or `api-key-example`:
Original: The `apiKey` scheme type contains an additional `name` property that configures the key name to use when the Open API service is invoked. Also, the format to pass the key depends on the value of the in property.
Revised: The `apiKey` scheme type contains an additional `name` property that configures the key name to use when the Open API service is invoked. Also, the format to pass the key depends on the value of the `in` property.
Original: The following example shows how to secure a workflow operation using the HTTP basic authentication scheme. The `security-example.json` file defines an OpenAPI service with a single operation, `sayHelloBasic`, which uses the `http-basic-example` security scheme. You can configure credentials using application properties or environment variables.
Revised: The following example shows how to secure a workflow operation using the HTTP basic authentication scheme. The `security-example.json` file defines an OpenAPI service with a single operation, `sayHelloBasic`, which uses the `http-basic-example` security scheme. You can configure credentials using application properties, the worfklow ConfigMap, or environment variables.
Original: This procedure describes how to define and apply the necessary configuration properties for security schemes declared in the OpenAPI specification file. You can use either `application.properties`, the ConfigMap associated to your workflow, or environment variables to provide these credentials.
Revised: This procedure describes how to define and apply the necessary configuration properties for security schemes declared in the OpenAPI specification file. You can use either `application.properties`, the `ConfigMap` associated to your workflow, or environment variables to provide these credentials.
Original: The following example shows how to secure a workflow operation using the HTTP basic authentication scheme. The `security-example.json` file defines an OpenAPI service with a single operation, `sayHelloBasic`, which uses the `http-basic-example` security scheme. You can configure credentials using application properties, worfklow `ConfigMap`, or environment variables.
Revised: The following example shows how to secure a workflow operation using the HTTP basic authentication scheme. The `security-example.json` file defines an OpenAPI service with a single operation, `sayHelloBasic`, which uses the `http-basic-example` security scheme. You can configure credentials using application properties, the worfklow `ConfigMap`, or environment variables.
Original: The following example shows how to secure an OpenAPI operation using the HTTP Bearer authentication scheme. The `security-example.json` file defines an OpenAPI service with the `sayHelloBearer` operation, which uses the `http-bearer-example` scheme for authentication. To access the secured operation during workflow execution, you must configure a Bearer token using application properties or environment variables.
Revised: The following example shows how to secure an OpenAPI operation using the HTTP Bearer authentication scheme. The `security-example.json` file defines an OpenAPI service with the `sayHelloBearer` operation, which uses the `http-bearer-example` scheme for authentication. To access the secured operation during workflow execution, you must configure a Bearer token using application properties, the workflow `ConfigMap`,  or environment variables.
Original: The following example shows how to secure an OpenAPI service operation using the `apiKey` authentication scheme. The `security-example.json` file defines the `sayHelloApiKey` operation, which uses the `api-key-example` security scheme. You can configure the API key using application properties or environment variables.
Revised: The following example shows how to secure an OpenAPI service operation using the `apiKey` authentication scheme. The `security-example.json` file defines the `sayHelloApiKey` operation, which uses the `api-key-example` security scheme. You can configure the API key using application properties, the workflow `ConfigMap', or environment variables.
Original: This procedure describes how to define and apply the necessary configuration properties for security schemes declared in the OpenAPI specification file. You can use either `application.properties`, the `ConfigMap` associated to your workflow, or environment variables to provide these credentials.
Revised: This procedure describes how to define and apply the necessary configuration properties for security schemes declared in the OpenAPI specification file. You can use either `application.properties`, the `ConfigMap` associated to your workflow, or environment variables in the `SonataFlow` CR to provide these credentials.
Original: ----
Revised: 
Example of configuring the credentials by using the workflow `ConfigMap`:
[source, yaml]
apiVersion: v1
data:
application.properties: |
quarkus.openapi-generator.security_example_json.auth.http_basic_example.username=myuser
quarkus.openapi-generator.security_example_json.auth.http_basic_example.password=mypassword
kind: ConfigMap
metadata:
labels:
app: example-workflow
name: example-workflow-props
namespace: example-namespace

Example of configuring the credentials by using environment variables in the `SonataFlow` CR:


[source, yaml]
apiVersion: sonataflow.org/v1alpha08
kind: SonataFlow
metadata:
name: example-workflow
namespace: example-namespace
annotations:
sonataflow.org/description: Example Workflow
sonataflow.org/version: 0.0.1
sonataflow.org/profile: preview
spec:
podTemplate:
container:
env:
value: myuser
value: mypassowrd
flow:
# workflow definition was omitted for simplicity
Original: To secure an OpenAPI service operation, define a security scheme by using the OpenAPI specification. These schemes are in the `Security Scheme Object` section of the OpenAPI specification file. When a workflow invokes an operation, it uses the defined security scheme to determine the required authentication configuration.
Revised: To secure an OpenAPI service operation, define a `Security Scheme` by using the OpenAPI specification. These schemes are in the `securitySchemes` section of the OpenAPI specification file. You must configure the operation by adding a `Security Requirement` that refers to that `Security Scheme`. When a workflow invokes such operation, that information is used to determine the required authentication configuration.
Original: The following example shows how to secure an OpenAPI service operation using the `apiKey` authentication scheme. The `security-example.json` file defines the `sayHelloApiKey` operation, which uses the `api-key-example` security scheme. You can configure the API key using application properties, the workflow `ConfigMap', or environment variables.
Revised: The following example shows how to secure an OpenAPI service operation using the `apiKey` authentication scheme. The `security-example.json` file defines the `sayHelloApiKey` operation, which uses the `api-key-example` security scheme. You can configure the API key using application properties, the workflow `ConfigMap`, or environment variables.
Original: ** `security_scheme_name` is the sanitized name of the security scheme object definition in the OpenAPI specification file, such as http_basic_example or api_key_example.
Revised: ** `security_scheme_name` is the sanitized name of the security scheme object definition in the OpenAPI specification file, such as http_basic_example or api_key_example. To sanitize this name, you must replace all non-alphabetic characters with underscores _.
Original: OAuth 2.0 token management is handled by a Quarkus `OidcClient`. To enable this integration, you must add the Quarkus OIDC Client Filter extension to your project as shown in the following examples:
Revised: OAuth 2.0 token management is handled by a Quarkus `OidcClient`. To enable this integration, you must add the Quarkus OIDC Client Filter, and the Quarkus OpenApi Generator OIDC extensions to your project as shown in the following examples:
Revised: .Example of adding extensions using `preview` profile

[source,yaml,subs="attributes+"]
apiVersion: sonataflow.org/v1alpha08
kind: SonataFlowPlatform
metadata:
name: sonataflow-platform-example
namespace: example-namespace
spec:
build:
template:
buildArgs:
value: io.quarkus:quarkus-oidc-client-filter:{ServerlessLogicQuarkusVersion},io.quarkiverse.openapi.generator:quarkus-openapi-generator-oidc:{ServerlessLogicOauthDependencyVersion}

[NOTE]
====
Extensions added in the `SonataFlowPlatform` CR are included for all the workflows that you deploy in that namespace with the `preview` profile.
====
Original: The tokens are automatically passed to downstream services while the workflow is active. When the workflow enters a waiting state such as a timer or event-based pause, the token propagation stops. After the workflow resumes, tokens are not re-propagated automatically. You must manage re-authentication if needed.
Revised: The tokens are automatically passed to downstream services while the workflow is active. When the workflow enters a waiting state, such as a timer or event-based pause, the token propagation stops. After the workflow resumes, tokens are not re-propagated automatically. You must manage re-authentication if needed.
Original: The following example shows how to secure an OpenAPI operation using the OAuth 2.0 `clientCredentials` flow. The OpenAPI specification defines the `sayHelloOauth2` operation, which uses the `oauth-example` security scheme. Unlike simpler authentication methods such as HTTP Basic or API keys, OAuth 2.0 authentication requires additional integration with the Quarkus OpenID Connect (OIDC) Client.
Revised: The following example shows how to secure an OpenAPI operation using the OAuth 2.0 `clientCredentials` flow. The OpenAPI specification defines the `sayHelloOauth2` operation, which uses the `oauth-example` security scheme. Unlike simpler authentication methods, such as HTTP Basic or API keys, OAuth 2.0 authentication requires additional integration with the Quarkus OpenID Connect (OIDC) Client.
Original: * `oauth_example` matches the sanitized name of the `oauth-example` scheme in the OpenAPI file. The link between the sanitized scheme name and the corresponding `OidcClient` is by using that simple naming convention.
Revised: * `oauth_example` matches the sanitized name of the `oauth-example` scheme in the OpenAPI file. The link between the sanitized scheme name and the corresponding `OidcClient` is achieved by using that simple naming convention.
Original: :ServerlessLogicQuarkusVersion: 3.8.6.redhat-00004
Revised: :ServerlessLogic-DDL-Script-url: link:https://maven.repository.redhat.com/ga/org/kie/kogito/kogito-ddl/9.103.0.redhat-00003/kogito-ddl-9.103.0.redhat-00003-db-scripts.zip[kogito-ddl-9.103.0.redhat-00003-db-scripts.zip]
Original: Cluster administrators can configure the Insight Operator to obfuscate data from the Deployment Validation Operator (DVO), if the Operator is installed. When the `workload_names` value is added to the *insights-config* `ConfigMap` object, workload names—rather than UIDs—are displayed in Insights for Openshift, making them more recognizable for cluster administrators.
Revised: As a cluster administrator, you can configure the Insights Operator to obfuscate data from the optionally installed Deployment Validation Operator (DVO).

To display recognizable workload names rather than UIDs in *Insights for Openshift*, you can add the `workload_names` parameter to the *insights-config* `ConfigMap` object.
Original: * *Insight Operator*: By default, {product-title} installs and enables the Insight Operator, which reports configuration and component failure status every two hours. The Insight Operator helps to:
Revised: * *Insights Operator*: By default, {product-title} installs and enables the Insights Operator, which has the following uses:
** Reports the configuration and component failure status every two hours.
** Identifies potential cluster issues proactively.
** Provides a solution and preventive action in {cluster-manager-first}.
Original: Use the custom parameter expansion feature only when you cannot use the Tekton `PipelineRun` parameters because Tekton parameters are defined in a `Pipeline` resource and customized alongside it inside a Git repository. However, custom parameters are defined and customized where the `Repository` CR is located. So, you cannot manage your CI/CD pipeline from a single point.
Revised: Use the custom parameter expansion feature only when you cannot use the Tekton `PipelineRun` parameters because Tekton parameters are defined in a `Pipeline` resource and customized alongside it inside a Git repository. However, custom parameters are defined and customized where the `Repository` CR is located. Therefore, you cannot manage your CI/CD pipeline from a single point.
Original: This release of {SMProductName} is included with the {SMProductName} Operator 3.0.1 and is supported on OpenShift Container Platform 4.14 and later. This release addresses Common Vulnerabilities and Exposures (CVEs) and is supported on {ocp-product-title} 4.14 and later. For supported component versions for 3.0.1, see "Service Mesh version support tables".
Revised: This release of {SMProductName} is included with the {SMProductName} Operator 3.0.1 and is supported on {ocp-product-title} 4.14 and later. This release addresses Common Vulnerabilities and Exposures (CVEs) and is supported on {ocp-product-title} 4.14 and later. For supported component versions for 3.0.1, see "Service Mesh version support tables".