gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: * Previously, an error occurred in {hcp-capital}-managed clusters because of the omission of `shutdown-watch-termination-grace-period` in the `kube-apiserver` configuration. This led to unstable shutdown of applications in {hcp}-managed clusters. With this release, an update improves the shutdown process of applications in {hcp}-managed clusters, providing a grace period for the `kube-apiserver` configuration. During a shutdown, the application stability is improved and potential errors are decreased. (link:https://issues.redhat.com/browse/OCPBUGS-53404[OCPBUGS-53404])
Revised: * Previously, an error occurred in {hcp}-managed clusters because of the omission of the `shutdown-watch-termination-grace-period` setting in the `kube-apiserver` configuration. This error led to the unstable shutdown of applications in {hcp}-managed clusters. With this release, an update improves the shutdown process of applications in {hcp}-managed clusters, providing a grace period for the `kube-apiserver` configuration. During a shutdown, the application stability is improved and potential errors are decreased. (link:https://issues.redhat.com/browse/OCPBUGS-53404[OCPBUGS-53404])
Original: * Previously, an issue with the version of `github.com/sherine-k/catalog-filter`, `oc-mirror` stopped, caused instability in the mirroring process. With this release, the `github.com/sherine-k/catalog-filter` element in the `go.mod` file is updated, which solves the problem and ensures a stable and reliable mirroring process. (link:https://issues.redhat.com/browse/OCPBUGS-54727[OCPBUGS-54727])
Revised: * Previously, an issue with the version of the `github.com/sherine-k/catalog-filter` element stopped, causing instability in the mirroring process. With this release, the `github.com/sherine-k/catalog-filter` element in the `go.mod` file is updated, which solves the problem and ensures a stable and reliable mirroring process. (link:https://issues.redhat.com/browse/OCPBUGS-54727[OCPBUGS-54727])
Original: * Previously, an iteration counter increment omission in the `scrapeCache` led to an incorrect series count for subsequent scrapes. This resulted in interrupted monitoring and potential data loss during the Prometheus scrape process. With this release, an update ensures uninterrupted monitoring, because Prometheus continues scraping and processing data while parsing errors. (link:https://issues.redhat.com/browse/OCPBUGS-54940[OCPBUGS-54940])
Revised: * Previously, an iteration counter increment omission in the `scrapeCache` setting led to an incorrect series count for subsequent scrapes. As a result, monitoring was interrupted and data could potentially be lost during the Prometheus scrape process. With this release, an update ensures uninterrupted monitoring, because Prometheus continues scraping and processing data while parsing errors. (link:https://issues.redhat.com/browse/OCPBUGS-54940[OCPBUGS-54940])
Original: //=== {op-system-base-full}
//Image mode for RHEL here if GA; otherwise leave in TP
Revised: Installing {microshift-short} by using a `bootc` container image is now generally available. Previously available as a Technology Preview feature, {op-system-image} is a deployment method that uses a container-native approach to build, deploy, and manage the operating system as a bootc container image. See xref:../microshift_install_bootc/microshift-about-rhel-image-mode.adoc#microshift-about-rhel-image-mode[Understanding image mode for RHEL with {microshift-short}] for more information.
Original: Image mode for {op-system-base-full} is a Technology Preview deployment method that uses a container-native approach to build, deploy, and manage the operating system as a bootc image. By using bootc, you can build, deploy, and manage the operating system as if it is any other container.
Revised: By using image mode for {op-system-base}, you can administer the operating system just as you would any other container. Image mode for {op-system-base} is a deployment method that uses a container-native approach to build, deploy, and manage the operating system as a bootc image.
Original: Image mode for {op-system-base-full} is a Technology Preview deployment method that uses a container-native approach to build, deploy, and manage the operating system as a bootc image. By using bootc, you can build, deploy, and manage the operating system as if it is any other container.
Image mode splits the creation and installation of software changes into two steps: one on a build system and one on a running target system.
* In the build-system step, a Podman build inspects the RPM files available for installation, determines any dependencies, and creates an ordered list of chained steps to complete, with the end result being a new operating system available to install.
* In the running-target-system step, a bootc update downloads, unpacks, and makes the new operating system bootable alongside the currently running system. Local configuration changes are carried forward to the new operating system, but do not take effect until the system is rebooted and the new operating system image replaces the running image.
Revised: * In the running-target-system step, a bootc update downloads the operating system, unpacks it, and prepares it to be started alongside the currently running system. Local configuration changes are carried forward to the new operating system. These changes take effect only when the system is restarted and the new operating system image replaces the previously running one.
Original: To use image mode for {op-system-base}, ensure that the following resources are available:
* You can use image mode for RHEL with a {microshift-short} cluster on AArch64 or x86_64 system architectures.
The workflow for using image mode with {microshift-short} includes the following steps:
. Find and use a prebuilt {microshift-short} container image to install {op-system-base-full}.
Revised: . If the prebuilt {microshift-short} container image requires customization, build a custom {microshift-short} container image.
Original: * xref:../../installing/installing_gcp/installation-config-parameters-gcp.adoc#installation-configuration-parameters-additional-gcp_installation-config-parameters-gcp[Additional Google Cloud Platform (GCP) configuration parameters]
Revised: * xref:../../installing/installing_gcp/installation-config-parameters-gcp.adoc#installation-configuration-parameters-additional-gcp_installation-config-parameters-gcp[Additional {gcp-first} configuration parameters]
Original: You can install a cluster with a custom DNS solution that you manage. As a result, you can manage these records in your own system rather than managing the records in the cluster. For example, your organization's security policies might not allow the use of public DNS services such as Google Cloud DNS. In such scenarios, you can use your own DNS service to bypass the public DNS service. You can manage your DNS only for the IP addresses of the API server and the ingress service.
Revised: You can install a cluster with a DNS solution that you manage. As a result, you can manage the API and Ingress DNS records in your own system rather than managing the records in the cluster. For example, your organization's security policies might not allow the use of public DNS services such as Google Cloud DNS. In such scenarios, you can use your own DNS service to bypass the public DNS service. You can manage your DNS only for the API and Ingress servers.
Original: You can install a cluster with a DNS solution that you manage. As a result, you can manage the API and Ingress DNS records in your own system rather than managing the records in the cluster. For example, your organization's security policies might not allow the use of public DNS services such as Google Cloud DNS. In such scenarios, you can use your own DNS service to bypass the public DNS service. You can manage your DNS only for the IP addresses of the API and Ingress servers.
Revised: You can install a cluster with a DNS solution that you manage. As a result, you can manage the API and Ingress DNS records in your own system rather than adding the records to the cloud's DNS. For example, your organization's security policies might not allow the use of public DNS services such as Google Cloud DNS. In such scenarios, you can use your own DNS service to bypass the public DNS service and manage your own  DNS only for the API and Ingress services.
This solution only requires you configure your own DNS solution after a successful cluster install.
Original: If you enable user-managed DNS during installation, the installation program will not provision DNS records for the API and Ingress servers. To ensure that you can log in to your cluster, you must provision the DNS records for the API and Ingress servers after installation.
Revised: If you enable user-managed DNS during installation, the installation program will provision DNS records for the API and Ingress servers only within the cluster. To ensure access from outside the cluster, you must provision DNS records in an external DNS service of your choosing for the API and Ingress services after installation.
Original: |Enables user-provisioned DNS instead of the default cluster-provisioned DNS solution. If you use this feature, you must provide your own DNS solution that includes records for `api.<cluster_name>.<base_domain>.` and `*.apps.<cluster_name>.<base_domain>.`.
|`Enabled` or `Disabled`. The default value is `Disabled`. `userProvisionedDNS` is a Technology Preview feature only.
Revised: |Enables user-provisioned DNS instead of the default cluster-provisioned DNS solution. If you use this feature, you must provide your own DNS solution that includes records for `api.<cluster_name>.<base_domain>.` and `*.apps.<cluster_name>.<base_domain>.`. `userProvisionedDNS` is a Technology Preview feature.
|`Enabled` or `Disabled`. The default value is `Disabled`.
Original: Before you use this feature, you must add the parameter `userProvisionedDNS` to the `install-config.yaml` file and enable the parameter. For more information, see "Enabling a user-managed DNS".
Revised: Before you use this feature, you must add the `userProvisionedDNS` parameter to the `install-config.yaml` file and enable the parameter. For more information, see "Enabling a user-managed DNS".
Original: Use the IP address of the API server to provision your own DNS record with the hostname `api.<cluster_name>.<base_domain>.`, using your cluster name and base cluster domain. Use the IP address of the ingress service to provision your own DNS record with the hostname `*.apps.<cluster_name>.<base_domain>.`, using your cluster name and base cluster domain.
Revised: Use the IP address of the API server to provision your own DNS record with the `api.<cluster_name>.<base_domain>.` hostname by using your cluster name and base cluster domain. Use the IP address of the ingress service to provision your own DNS record with the `*.apps.<cluster_name>.<base_domain>.` hostname by using your cluster name and base cluster domain.
Original: include::modules/oc-mirror-signature-mirroring.adoc[leveloffset=+1]
Revised: [id="oc-mirror-about-sig-mirroring-verification_{context}"]
== About signature mirroring and verification in oc-mirror plugin v2

Starting with {product-title} 4.19, the `oc-mirror` plugin v2 supports mirroring and verifying cosign tag-based signatures for container images.
Original: Starting with {product-title}, oc-mirror plugin v2 supports signature verification, which is disabled by default. You can verify the authenticity of the container images. If a signature mismatch is detected, the mirroring workflow will fail.
Revised: Starting with {product-title} 4.19, oc-mirror plugin v2 supports signature verification, which is disabled by default. You can verify the authenticity of the container images. If a signature mismatch is detected, the mirroring workflow will fail.
Original: Starting with {product-title} 4.19, oc-mirror plugin v2 supports signature verification, which is disabled by default. You can verify the authenticity of the container images. If a signature mismatch is detected, the mirroring workflow will fail.
Revised: Starting with {product-title} 4.19, oc-mirror plugin v2 supports signature verification, which is disabled by default. When enabled, the plugin verifies that container images match their signatures, ensuring they have not been altered and come from trusted sources. If a signature mismatch is detected, the mirroring workflow will fail.
Original: Starting with {product-title} 4.19, oc-mirror plugin v2 supports signature verification, which is disabled by default. When enabled, the plugin verifies that container images match their signatures, ensuring they have not been altered and come from trusted sources. If a signature mismatch is detected, the mirroring workflow will fail.
Revised: Starting with {product-title} 4.19, the oc-mirror plugin v2 supports signature verification, which is disabled by default. When enabled, the plugin verifies that container images match their signatures, ensuring they have not been altered and come from trusted sources. If a signature mismatch is detected, the mirroring workflow will fail.
Original: You can collect information from a MicroShift container using an optional MicroShift observability service. This service transmits container data to remote endpoints for monitoring and analysis. This service is enabled by default. To disable the service, see "Opting out of remote health reporting".
Revised: You can collect information from a MicroShift host/system/service using an optional MicroShift observability service. This service transmits container data to remote endpoints for monitoring and analysis. This service is enabled by default. To disable the service, see "Opting out of remote health reporting".
Original: You can collect information from a MicroShift container using an optional MicroShift observability service. This service transmits container data to remote endpoints for monitoring and analysis. This service is enabled by default. To disable the service, see "Opting out of remote health reporting".
Revised: You can collect information from a MicroShift container using an optional MicroShift observability service. This service transmits container data to remote endpoints for monitoring and analysis. This service is disabled by default. To disable the service, see "Opting out of remote health reporting".
Original: Replace the variable `${env:K8S_NODE_NAME}` with the IP address or host name of the remote back end. This IP address resolves to the local node's host name. Any unreachable endpoint is reported in the {microshift-short} service logs.
Revised: Replace the variable `${env:K8S_NODE_NAME}` with the IP address or host name of the remote back end. This IP address resolves to the local node's host name. Any unreachable endpoint is reported in the `microshift-observability` service logs.
Original: The `Opentelemtry-collector.yaml` file includes a minimal set of data for monitoring the system, node, and workload resource use for the cpu, memory, disk drive, and network. All warnings for cluster events are included in the collected data. This setting transmits the following data:
Revised: The `opentelemetry-collector.yaml` file includes a minimal set of data for monitoring the system, node, and workload resource use for the CPU, memory, disk drive, and network. All warnings for cluster events are included in the collected data. This setting transmits the following data:
Original: <1> Replace the variable `${env:K8S_NODE_NAME}` with the IP address or host name of the remote back end. This IP address resolves to the local node's host name. Any unreachable endpoint is reported in the {microshift-short} service logs.
Revised: <1> Replace the variable `${env:K8S_NODE_NAME}` with the IP address or host name of the remote back end. This IP address resolves to the local node's host name. Any unreachable endpoint is reported in the `microshift-observability` service logs.
Original: Replace the variable `${env:K8S_NODE_NAME}` with the IP address or host name of the remote back end. This IP address resolves to the local node's host name. Any unreachable endpoint is reported in the {microshift-short} service logs.
Revised: Replace the values of fields `exporters.otlp.endpoint` and `services.telemetry.metrics.readers[0].endpoint` with the IP address or host name of the remote back end. This IP address resolves to the local node's host name. Any unreachable endpoint is reported in the {microshift-short} service logs.
Original: . Update the `/etc/microshift/config.yaml` to specify an OLTP-compatible endpoint with the following information. The endpoint must link to an IP address or host name, and port number of an OTLP service.
Revised: . Update the `/etc/microshift/observability/opentelemetry-collector.yaml` to specify an OTLP-compatible endpoint with the following information. The endpoint must link to an IP address or host name, and port number of an OTLP service.
Original: exporters:
  otlp:
    sending_queue:
      storage: file_storage

Revised: exporters:
otlp:
sending_queue:
storage: file_storage

endpoint: ${env:K8S_NODE_NAME}:4317 <1>
tls:
insecure: true
(...)

service:
(...)
telemetry:
metrics:
readers:
exporter:
otlp:
# Endpoint must point to an ip or hostname and port of an otlp service. Here, the K8S_NODE_NAME is used
# because it will be resolved to the local node's hostname automatically. An unreachable endpoint will
# reported in the logs of the microshift-observability service.
protocol: http/protobuf
endpoint: http://${env:K8S_NODE_NAME}:4318
Original: Replace the values of the `exporters.otlp.endpoint` and `services.telemetry.metrics.readers[0].endpoint` fields with the IP address or host name of the remote back end. This IP address resolves to the local node's host name. Any unreachable endpoint is reported in the {microshift-short} observability service logs.
Revised: Replace the values of the `exporters.otlp.endpoint` and `services.telemetry.metrics.readers[0].periodic.otlp.endpoint` fields with the IP address or host name of the remote back end. This IP address resolves to the local node's host name. Any unreachable endpoint is reported in the {microshift-short} observability service logs.
Original: The `opentelemtry-collector.yaml` file includes a minimal set of data for monitoring the system, node, and workload resource use for the CPU, memory, disk drive, and network. All warnings for cluster events are included in the collected data. This setting transmits the following data:
Revised: The `opentelemetry-collector.yaml` file includes a minimal set of data for monitoring the system, node, and workload resource use for the CPU, memory, disk drive, and network. All cluster events are included in the collected data. This setting transmits the following data:
Original: * CPU, memory, disk, and network metrics of containers, pods, and node
* Kubernetes events (warnings only)
* Host cpu, memory, disk, and network metrics
* System journals for certain {microshift-short} services, dependencies, and priorities
Revised: * Resource usage metrics of MicroShift's Containers, Pods, Volumes, and Node
* Kubernetes Events
* Host's CPU, memory, disk, and network usage metrics
* System journals for selected MicroShift services and dependencies, priority < Info
* Metrics exposed by Pods that have "prometheus.io/scrape": "true" annotation
Original: <1> Replace the variable `${env:K8S_NODE_NAME}` with the IP address or host name of the remote back end. This IP address resolves to the local node's host name. Any unreachable endpoint is reported in the `microshift-observability` service logs.
Revised: <1> Replace the variable `${env:K8S_NODE_NAME}` with the IP address or host name of the remote back end. This IP address resolves to the local node's host name. Any unreachable endpoint is reported in the `microshift-observability` service logs.
<2> Replace the variable `${env:K8S_NODE_NAME}` with the IP address or host name of the remote back end. This IP address resolves to the local node's host name. Any unreachable endpoint is reported in the `microshift-observability` service logs.
Original: * CPU, memory, disk, and network metrics of containers, pods, and node
* Kubernetes events (warnings only)
* Host cpu, memory, disk, and network metrics
* System journals for certain {microshift-short} services, dependencies, and priorities
Revised: * CPU, memory, disk, and network metrics of containers, pods, and node
* Kubernetes events
* Host cpu, memory, disk, and network metrics
* System journals for certain {microshift-short} services, dependencies
* Metrics exposed by Pods that have "prometheus.io/scrape": "true" annotation
Original:     endpoint: ${env:K8S_NODE_NAME}:4317 <1>
    tls:
      insecure: true
(...)
service:
(...)
  telemetry:
    metrics:
      readers:
        - periodic:
            exporter:
              otlp:
                protocol: http/protobuf
                endpoint: http://${env:K8S_NODE_NAME}:4318 <1>
----  
<1> Replace `${env:K8S_NODE_NAME}` with the IP address or host name of the remote back end. This IP address will resolve to the local node's host name. An unreachable endpoint is reported in the {microshift-short} service logs.    
Revised: endpoint: ${env:OTEL_BACKEND}:4317 <1>
tls:
insecure: true
(...)
service:
(...)
telemetry:
metrics:
readers:
exporter:
otlp:
protocol: http/protobuf
endpoint: http://${env:OTEL_BACKEND}:4318 <1>
<1> Replace `${env:OTEL_BACKEND}` with the IP address or host name of the remote back end. This IP address will resolve to the local node's host name. An unreachable endpoint is reported in the {microshift-short} service logs.
Original: <1> Replace the variable `${env:K8S_NODE_NAME}` with the IP address or host name of the remote back end. This IP address resolves to the local node's host name. Any unreachable endpoint is reported in the `microshift-observability` service logs.
<2> Replace the variable `${env:K8S_NODE_NAME}` with the IP address or host name of the remote back end. This IP address resolves to the local node's host name. Any unreachable endpoint is reported in the `microshift-observability` service logs.
Revised: <1> Replace the variable `${env:OTEL_BACKEND}` with the IP address or host name of the remote back end. This IP address resolves to the local node's host name. Any unreachable endpoint is reported in the `microshift-observability` service logs.
<2> Replace the variable `${env:OTEL_BACKEND}` with the IP address or host name of the remote back end. This IP address resolves to the local node's host name. Any unreachable endpoint is reported in the `microshift-observability` service logs.
Original: <1> Replace the variable `${env:K8S_NODE_NAME}` with the IP address or host name of the remote back end. This IP address resolves to the local node's host name. Any unreachable endpoint is reported in the {microshift-short} service logs.

<2> Replace the variable `${env:K8S_NODE_NAME}` with the IP address or host name of the remote back end. This IP address resolves to the local node's host name. Any unreachable endpoint is reported in the {microshift-short} service logs.
Revised: <1> Replace the variable `${env:OTEL_BACKEND}` with the IP address or host name of the remote back end. This IP address resolves to the local node's host name. Any unreachable endpoint is reported in the {microshift-short} service logs.

<2> Replace the variable `${env:OTEL_BACKEND}` with the IP address or host name of the remote back end. This IP address resolves to the local node's host name. Any unreachable endpoint is reported in the {microshift-short} service logs.
Original: You can configure {microshift-short} Observability after it is installed to identify a valid endpoint.

[NOTE]
====
You can specify any OpenTelemetry Protocol (OTLP)-compatible endpoint for each configuration before starting {microshift-short}. If an endpoint is not specified, {microshift-short} Observability will not start.
====
Revised: You must configure {microshift-short} Observability after it is installed by specifying a valid endpoint. If an endpoint is not specified, {microshift-short} Observability will not start.

You can specify any OpenTelemetry Protocol (OTLP)-compatible endpoint for each configuration before starting {microshift-short}.