gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: // * service-mesh-docs-main/install/ossm-installing-openshift-service-mesh.adoc
= Installing cert-manager
//TP1 content influx. Title, etc may change.
//Content is very similar to 2.x content
//all kinds of formatting things to fix. want to see if a build will generate to have a look, and see how it fits structurally with the IA.
Revised: = Integrating Service Mesh with the cert-manager Operator by using the Istio-CSR agent
Original: // * service-mesh-docs-main/install/ossm-installing-openshift-service-mesh.adoc
= Installing cert-manager
//TP1 content influx. Title, etc may change.
//Content is very similar to 2.x content
//all kinds of formatting things to fix. want to see if a build will generate to have a look, and see how it fits structurally with the IA.
You can integrate cert-manager with {SMProduct} by deploying `istio-csr` and then creating an `Istio` resource that uses the `istio-csr` agent to process workload and control plane certificate signing requests. This example creates a self-signed `Issuer`, but any other `Issuer` can be used instead.
Revised: You can integrate the cert-manager Operator with {SMProduct} by deploying the `istio-csr` agent and configuring an `{istio}` resource that uses the `istio-csr` agent to process workload and control plane certificate signing requests. The following procedure creates a self-signed `issuer` object.
Original: // * service-mesh-docs-main/install/ossm-installing-openshift-service-mesh.adoc
= Installing cert-manager
//TP1 content influx. Title, etc may change.
//Content is very similar to 2.x content
//all kinds of formatting things to fix. want to see if a build will generate to have a look, and see how it fits structurally with the IA.
You can integrate cert-manager with {SMProduct} by deploying `istio-csr` and then creating an `Istio` resource that uses the `istio-csr` agent to process workload and control plane certificate signing requests. This example creates a self-signed `Issuer`, but any other `Issuer` can be used instead.
[IMPORTANT]
====
You must install cert-manager before installing your `Istio` resource.
====
Revised: * You have a `IstioCNI` instance running in the cluster.
Original: ---
+
+
. Copy the `istio-ca` certificate to the `cert-manager` namespace so it can be used by istio-csr:
.. Copy the secret to a local file by running the following command:
Revised: The configuration disables the built-in CA server for {istio} and forwards certificate signing requests from `istiod` to the `istio-csr` agent. The `istio-csr` agent obtains certificates for both `istiod` and mesh workloads from the cert-manager Operator. The `istiod` TLS certificate that is generated by the `istio-csr` agent is mounted into the pod at a known location for use.
Original: ---
+
+
. Copy the `istio-ca` certificate to the `cert-manager` namespace so it can be used by istio-csr:
.. Copy the secret to a local file by running the following command:
$ oc get -n istio-system secret istio-ca -o jsonpath='{.data.tls\.crt}' | base64 -d > ca.pem
.. Create a secret from the local certificate file in the `cert-manager` namespace by running the following command:
Revised: .. Verify that the `istio` resource displays the "Ready" status condition by running the following command:
Original: You can uninstall the cert-manager with the {SMProduct} by using the following procedure. Before removing the following resources, verify that no {SMProductName} or {istio} components reference the `Istio-CSR` service or the certificates it issued. Removing these resources while they are still in use may disrupt mesh functionality.
Revised: You can uninstall the cert-manager Operator with {SMProduct} by completing the following procedure. Before you remove the following resources, verify that no {SMProductName} or {istio} components reference the `Istio-CSR` service or the certificates it issued. Removing these resources while they are still in use might disrupt mesh functionality.
Original: * Previously, Internet Small Computer System Interface (iSCSI) and Fibre Channel devices that were attached to a multipath device did not resolve correctly when these devices were partitioned. With this release, a fix ensures that partitioned multipath storage devices can now correctly resolve. (link:https://issues.redhat.com/browse/OCPBUGS-46038[OCPBUGS-46038])
[discrete]
[id="ocp-release-note-rhcos-bug-fixes_{context}"]
==== {op-system-first}
Revised: * Previously, on {azure-short} Red Hat OpenShift (ARO) when using Hypershift to create {hcp} clusters, the {azure-short} Disk Container Storage Interface (CSI) driver would not provision volumes successfully. With this release, this issue has been resolved, and the {azure-short} Disk CSI driver can provision volumes successfully. (link:https://issues.redhat.com/browse/OCPBUGS-46575[OCPBUGS-46575])
Original: * Previously, when the Cloud Credential Operator (CCO) did not provide credentials for Container Storage Interface (CSI) driver Operators, the CSI driver Operators remain in `Progressing=true` indefinitely, with a message indicating the Operator is waiting for `deployment/unavailable`. With this release, when progressing state lasts 15 minutes or longer, the operator changes to `Degraded=True`. (link:https://issues.redhat.com/browse/OCPBUGS-24588[OCPBUGS-24588])
Revised: * Previously, when the Cloud Credential Operator (CCO) did not provide credentials for Container Storage Interface (CSI) driver Operators, the CSI driver Operators remain in `Progressing=true` indefinitely, with a message indicating the `operator is waiting for deployment/unavailable`. With this release, when progressing state lasts 15 minutes or longer, the Operator changes to `Degraded=True`. (link:https://issues.redhat.com/browse/OCPBUGS-24588[OCPBUGS-24588])
Original: * Previously, when the Cloud Credential Operator (CCO) did not provide credentials for Container Storage Interface (CSI) driver Operators, the CSI driver Operators remain in `Progressing=true` indefinitely, with a message indicating the Operator is waiting for `deployment/unavailable`. With this release, when progressing state lasts 15 minutes or longer, the operator changes to `Degraded=True`. (link:https://issues.redhat.com/browse/OCPBUGS-24588[OCPBUGS-24588])
* Previously, Internet Small Computer System Interface (iSCSI) and Fibre Channel devices that were attached to a multipath device did not resolve correctly when these devices were partitioned. With this release, a fix ensures that partitioned multipath storage devices can now correctly resolve. (link:https://issues.redhat.com/browse/OCPBUGS-46038[OCPBUGS-46038])
Revised: * Previously, compute nodes with names that are 53 characters long and when using hostpath Container Storage Interface (CSI) driver cause volume provisioning to fail when using `--enable-node-deployment flag` on external-provisioner. With this release, this issue is resolved and there is no restriction on compute node name lengths.  (link:https://issues.redhat.com/browse/OCPBUGS-49805[OCPBUGS-49805])
Original: * Previously, when the Cloud Credential Operator (CCO) did not provide credentials for Container Storage Interface (CSI) driver Operators, the CSI driver Operators remain in `Progressing=true` indefinitely, with a message indicating the Operator is waiting for `deployment/unavailable`. With this release, when progressing state lasts 15 minutes or longer, the operator changes to `Degraded=True`. (link:https://issues.redhat.com/browse/OCPBUGS-24588[OCPBUGS-24588])
* Previously, Internet Small Computer System Interface (iSCSI) and Fibre Channel devices that were attached to a multipath device did not resolve correctly when these devices were partitioned. With this release, a fix ensures that partitioned multipath storage devices can now correctly resolve. (link:https://issues.redhat.com/browse/OCPBUGS-46038[OCPBUGS-46038])
[discrete]
[id="ocp-release-note-rhcos-bug-fixes_{context}"]
==== {op-system-first}
Revised: * Previously, on Azure Red Hat OpenShift when using {hcp} to create hosted clusters, the Azure Disk Container Storage Interface (CSI) driver would not provision volumes successfully. With this release, this issue has been resolved, and the Azure Disk CSI driver can provision volumes successfully. (link:https://issues.redhat.com/browse/OCPBUGS-46575[OCPBUGS-46575])
Original: * Previously, when the Cloud Credential Operator (CCO) did not provide credentials for Container Storage Interface (CSI) driver Operators, the CSI driver Operators remain in `Progressing=true` indefinitely, with a message indicating the Operator is waiting for `deployment/unavailable`. With this release, when progressing state lasts 15 minutes or longer, the operator changes to `Degraded=True`. (link:https://issues.redhat.com/browse/OCPBUGS-24588[OCPBUGS-24588])
* Previously, Internet Small Computer System Interface (iSCSI) and Fibre Channel devices that were attached to a multipath device did not resolve correctly when these devices were partitioned. With this release, a fix ensures that partitioned multipath storage devices can now correctly resolve. (link:https://issues.redhat.com/browse/OCPBUGS-46038[OCPBUGS-46038])
[discrete]
[id="ocp-release-note-rhcos-bug-fixes_{context}"]
==== {op-system-first}
* Previously, the GRUB bootloader was not automatically updated on {op-system} nodes. As a result, when nodes were created on {op-system-base} 8 and were subsequently updated to {op-system-base}, GRUB could not load the kernel as it uses a format that is not supported by older GRUB versions. With this release, a GRUB bootloader update is forced on nodes during updates to {product-title} 4.18 so that the issue does not occur on {product-title} {product-version}. (link:https://issues.redhat.com/browse/OCPBUGS-55144[OCPBUGS-55144])
Revised: * Previously, the Container Storage Interface (CSI) Operator was issuing warnings in the log about missing items that would become fatal in the future. With this release, the warnings are no longer issued. (link:https://issues.redhat.com/browse/OCPBUGS-44374[OCPBUGS-44374])
Original: * Previously, your cluster could experience a timeout when pulling images if you use Zscaler and scan all transfers. This was due to a hard-coded timeout value for image pulls. This fix increased the pull progress timeout of CRI-O to 30 seconds. As a result, your cluster should not experience timeout under these circumstances. (link:https://issues.redhat.com/browse/OCPBUGS-54662[OCPBUGS-54662])
Revised: * Previously, if your cluster used Zscaler and scanned all transfers, it could experience a timeout when pulling images. This problem was due to a hard-coded timeout value for image pulls. The pull progress timeout of CRI-O is now increased to 30 seconds. As a result, previously affected clusters should not experience timeouts. (link:https://issues.redhat.com/browse/OCPBUGS-54662[OCPBUGS-54662])
Original: * Previously, containers using the `container_logreader_t` SELinux domain to watch container logs on the host at /var/log could not access the logs. This was because the logs in `var/log/containers` were symbolic links. With this fix, containers can watch logs as expected.  (link:https://issues.redhat.com/browse/OCPBUGS-48555[OCPBUGS-48555])
Revised: * Previously, containers that used the `container_logreader_t` SELinux domain to watch container logs on the host at the `/var/log` location could not access the logs. This behavior occurred because the logs in the `var/log/containers` location were symbolic links. With this fix, containers can watch logs as expected. (link:https://issues.redhat.com/browse/OCPBUGS-48555[OCPBUGS-48555])
Original: * Previously, an end-of-file error  existed in the `json.NewDecoder` file when the file was in a loop operation. This error caused inconsistent application updates to namespaced policies that existed in multiple namespaces. This issue could potential cause security vulnerabilities for the cluster. With this release, a new policy buffer is added to `json.NewDecoder` when the file enter each loop operation, and test case is added for multiple namespaces. As a result, the policy buffer provides a robust decoding process for JSON policy files so that namespace policies receive updates without any issues. (link:https://issues.redhat.com/browse/OCPBUGS-48195[OCPBUGS-48195])
Revised: * Previously, an end-of-file error occurred in the `json.NewDecoder` file when the file was in a loop operation. This error caused inconsistent application updates to namespaced policies that existed in multiple namespaces. This issue could cause security vulnerabilities for the cluster. With this release, a new policy buffer is added to the `json.NewDecoder` file when the it enters each loop operation and a test case is added for multiple namespaces. As a result, the policy buffer provides a robust decoding process for JSON policy files so that namespace policies receive updates without any issues. (link:https://issues.redhat.com/browse/OCPBUGS-48195[OCPBUGS-48195])
Original: * Previously, there was an issue in the image reference digest calculation that led to a failed container creation based on the `schemaVersion 1` image. This issue prevented new deployment creations. With this release, the image digest calculation has been fixed and new operators can be installed. (link:https://issues.redhat.com/browse/OCPBUGS-42844[OCPBUGS-42844]) 
Revised: * Previously, there was an issue in the image reference digest calculation that led to failed container creation based on the `schemaVersion 1` image. This issue prevented new deployment creations. With this release, the image digest calculation has been fixed and new operators can be installed. (link:https://issues.redhat.com/browse/OCPBUGS-42844[OCPBUGS-42844])
Original: * Previously, for a Technology Preview-enabled cluster with Sigstore verification for payload images in `policy.json`, the Podman version in the base image did not support Sigstore configuration, so the new node is not available. With this release, the issue is fixed and the node is available. (link:https://issues.redhat.com/browse/OCPBUGS-38809[OCPBUGS-38809])
Revised: * Previously, for a Technology Preview-enabled cluster with Sigstore verification for payload images in the `policy.json` file, the Podman version in the base image did not support Sigstore configuration. This lack of support caused the new node to be unavailable. With this release, the issue is fixed and the node is available. (link:https://issues.redhat.com/browse/OCPBUGS-38809[OCPBUGS-38809])
Original: * Previously, CPUs for the last guaranteed pod admitted to a node remained allocated after the pod was deleted. As a consequence, this caused scheduling domain inconsistencies. With this release, CPUs allocated to guaranteed pods return to the pool of available CPU resources as expected, ensuring correct CPU scheduling for subsequent pods. (link:https://issues.redhat.com/browse/OCPBUGS-17792[OCPBUGS-17792])
Revised: * Previously, CPUs for the last guaranteed pod admitted to a node remained allocated after the pod was deleted. This behavior caused scheduling domain inconsistencies. With this release, CPUs that are allocated to guaranteed pods return to the pool of available CPU resources as expected, ensuring correct CPU scheduling for subsequent pods. (link:https://issues.redhat.com/browse/OCPBUGS-17792[OCPBUGS-17792])
Original: * Previously, when applying a performance profile to a node, {product-title} selected the appropriate profile based on the vendor identifier of the CPU unit on the node. Because of this, if a CPU uses a different vendor identifier that is not recognized, {product-title} failed to include the proper profile. For example the identifier might include APM, rather than ARM. With this fix, for CPUs that use the ARM architecture, the Operator now selects a profile based only on the architecture, and not the vendor identifier. As a result, the correct profile is applied. (link:https://issues.redhat.com/browse/OCPBUGS-52352[OCPBUGS-52352])
Revised: * Previously, when applying a performance profile to a node, {product-title} selected the appropriate profile based on the vendor identifier of the CPU unit on the node. Because of this behavior, if a CPU uses a different vendor identifier that is not recognized, {product-title} failed to include the proper profile. For example the identifier might include APM, rather than ARM. With this fix, for CPUs that use the ARM architecture, the Operator now selects a profile based only on the architecture, and not the vendor identifier. As a result, the correct profile is applied. (link:https://issues.redhat.com/browse/OCPBUGS-52352[OCPBUGS-52352])
Original: * Previously, the *Silence details* page had an incorrect link URL missing the `namespace` parameter, causing users to be unable to silence specific alerts in the dev console for certain versions, resulting in poor alert management. With this release, the undefined link in `SilencedAlertsList` has been fixed using the active namespace. As a result, the 'No Alert found' error is now resolved, and the *Alert details* page in {product-title} Monitoring is navigated to correctly. (link:https://issues.redhat.com/browse/OCPBUGS-48142[OCPBUGS-48142])
Revised: * Previously, the *Silence details* page had an incorrect link URL that was missing the `namespace` parameter, which caused users to be unable to silence specific alerts in the dev console for certain versions. This resulted in poor alert management. With this release, the undefined link in `SilencedAlertsList` has been fixed using the active namespace. As a result, the 'No Alert found' error is now resolved, and the *Alert details* page in {product-title} Monitoring is navigated to correctly. (link:https://issues.redhat.com/browse/OCPBUGS-48142[OCPBUGS-48142])
Original: * Previously, on the *Observe -> Alerting -> Silences* tab, the `DateTime` component changed the ordering of an event and its value. Because of this issue, you could not edit the `until` parameter for a silent alert in either the *Developer* or the *Administrator* perspective. With this release, a fix means to the `DateTime` component means that you can now edit the `until` parameter for a silent alert. (link:https://issues.redhat.com/browse/OCPBUGS-45801[OCPBUGS-45801]) 
Revised: * Previously, on the *Observe -> Alerting -> Silences* tab, the `DateTime` component changed the ordering of an event and its value. Because of this issue, you could not edit the `until` parameter for a silent alert in the web console. With this release, a fix means to the `DateTime` component means that you can now edit the `until` parameter for a silent alert. (link:https://issues.redhat.com/browse/OCPBUGS-45801[OCPBUGS-45801])
Original: * Previously, the `ContainerRuntimeConfig` incorrectly set the `--root` path for the `runc` runtime. This caused containers to run with an incorrect root path and led to issues with the container operations. With this release, the `--root` path for the container runtime is correct and matches the specified runtime, providing consistent operation. (link:https://issues.redhat.com/browse/OCPBUGS-47629[OCPBUGS-47629])
Revised: * Previously, the `ContainerRuntimeConfig` incorrectly set the `--root` path for the `runc` runtime. This caused containers to run with an incorrect root path and led to issues with container operations. With this release, the `--root` path for the container runtime is correct and matches the specified runtime, providing consistent operation. (link:https://issues.redhat.com/browse/OCPBUGS-47629[OCPBUGS-47629])
Original: * Previously, if you launched a cluster for an {aws-first} region for which an Amazon Machine Images (AMI) is not available, the installation might fail. This was problematic for OKD, which does not have an AMI for all of the AWS regions. With this release, an update adds a default region that is used in case the cluster is launched with a region is not available. (link:https://issues.redhat.com/browse/OCPBUGS-55231[OCPBUGS-55231])
Revised: * Previously, if you launched a cluster for an {aws-first} region for which an Amazon Machine Images (AMI) is not available, the installation might fail. This was problematic for OKD, which does not have an AMI for all of the AWS regions. With this release, an update adds a default region that is used in case the cluster is launched with a region is not available. (link:https://issues.redhat.com/browse/OCPBUGS-55231[OCPBUGS-55231])
Original: * Previously, users were not warned if their cluster contained {op-system-base-full} worker nodes, which are no longer supported in {product-title} 4.19 and later. With this release, the Machine Config Operator detects bare-{op-system-base} nodes and notifies users that they will not be compatible with {product-title} 4.19. (link:https://issues.redhat.com/browse/OCPBUGS-54611[OCPBUGS-54611])
Revised: * Previously, users were not warned if their cluster contained {op-system-base-full} worker nodes, which are no longer supported in {product-title} 4.19 and later. With this release, the Machine Config Operator detects bare-{op-system-base} nodes and notifies users that they are not compatible with {product-title} 4.19. (link:https://issues.redhat.com/browse/OCPBUGS-54611[OCPBUGS-54611])
Original: * Previously, when the Machine Config Operator (MCO) rebooted the node too quickly after staging an update, the update failed. With this release, the MCO waits for the staging operation to finish before rebooting the system, allowing the update to complete. (link:https://issues.redhat.com/browse/OCPBUGS-51150[OCPBUGS-51150])
Revised: * Previously, when the Machine Config Operator (MCO) rebooted a node too quickly after staging an update, the update failed. With this release, the MCO waits for the staging operation to finish before rebooting the system, allowing the update to complete. (link:https://issues.redhat.com/browse/OCPBUGS-51150[OCPBUGS-51150])
Original: It requires using the OVN-Kubernetes network plugin with the Observability feature. +
IMPORTANT: This feature is available as a Technology Preview.
- `EbpfManager`: Unsupported * . Use eBPF Manager to manage Network Observability eBPF programs. Pre-requisite: the eBPF Manager operator (or upstream bpfman operator) must be installed. +
- `UDNMapping`: Unsupported *. Enable interfaces mapping to User Defined Networks (UDN).  +
Revised: This feature requires mounting the kernel debug filesystem, so the eBPF agent pods must run as privileged. If the `spec.agent.ebpf.privileged` parameter is not set, a warning is reported.
Original: * Previously, the openshift-apiserver could panic when both image and error fields were unset during CRD request handling, this led to runtime crashes and instability in the API server under certain conditions. With this release, guard is added to ensure no panic occurs by safely handling the case when both fields are unset, resulting in a more robust and stable CRD request handling process without crashes. (link:https://issues.redhat.com/browse/OCPBUGS-45861[OCPBUGS-45861]) 
Revised: * Previously, the openshift-apiserver could panic when both image and error fields were unset during CRD request handling, this led to runtime crashes and instability in the API server under certain conditions. With this release, a guard is added to ensure no panic occurs by safely handling the case when both fields are unset, resulting in a more robust and stable CRD request handling process without crashes. (link:https://issues.redhat.com/browse/OCPBUGS-45861[OCPBUGS-45861])