gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: * Before this update, upgrading the {gitops-title} Operator to v1.15.1 raised a health check error that prevented Red Hat Advanced Cluster Management (ACM) policies from syncing. This update fixes the issue by adding a missing nil check to `status.placement` for *Policy*. link:https://issues.redhat.com/browse/GITOPS-6664[GITOPS-6664]
Revised: * Before this update, upgrading the {gitops-title} Operator to v1.15.1 raised a health check error that prevented Red Hat Advanced Cluster Management (ACM) policies from syncing. This update fixes the issue by adding a missing nil check to `.status.placement` for *Policy*. link:https://issues.redhat.com/browse/GITOPS-6664[GITOPS-6664]
Original: * With this update, a new checkbox, `.spec.SyncPolicy.Automated`, has been added to the Argo CD Application resource to explicitly enable or disable `automatedSync`. This option provides the following advantages:
Revised: * With this update, a new check box, `.spec.SyncPolicy.Automated`, has been added to the Argo CD Application resource to explicitly enable or disable `automatedSync`. This option provides the following advantages:
Original: * Before this update, Argo CD components, such as, `server`, `repo-server`, and `application-controller` could crash when accessing the Redis instance due to network or DNS instabilities within the cluster. This issue stemmed from a race condition in the `go-redis` client library when multiple connections in a connection pool call the `dial hook` function. With this update, this issue is fixed. This update resolves the issue by integrating an updated `go-redis` client library that eliminates race conditions during `dial hook` function calls. It also improves the handling and recovery from network and DNS errors, ensuring greater stability for Argo CD components. link:https://issues.redhat.com/browse/GITOPS-6287[GITOPS-6287]
Revised: * Before this update, Argo CD components, such as, `server`, `repo-server`, and `application-controller`, could crash when accessing the Redis instance due to network or DNS instabilities within the cluster. This issue stemmed from a race condition in the `go-redis` client library when multiple connections in a connection pool call the `dial hook` function. With this update, this issue is fixed. This update resolves the issue by integrating an updated `go-redis` client library that eliminates race conditions during `dial hook` function calls. It also improves the handling and recovery from network and DNS errors, ensuring greater stability for Argo CD components. link:https://issues.redhat.com/browse/GITOPS-6287[GITOPS-6287]
Original: * Before this update, monitoring support for workloads deployed in {OCP} namespaces, prefixed with `openshift-`, was available by default. Argo CD monitoring worked automatically only when deployed in {OCP} managed namespaces. With this update, monitoring support for Argo CD deployed in non-{OCP} namespaces requires monitoring for user-defined projects to be explicitly enabled in {OCP} Monitoring. For more information, see link:https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/monitoring/configuring-user-workload-monitoring#configurable-monitoring-components_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]. link:https://issues.redhat.com/browse/GITOPS-6251[GITOPS-6251]
Revised: * Before this update, monitoring support for workloads deployed in {OCP} namespaces was available by default, provided the monitoring was enabled in ArgoCD CR.  With this update, Argo CD monitoring works automatically only when deployed in {OCP} managed namespaces. Monitoring support for Argo CD deployed in non-{OCP} namespaces requires monitoring for user-defined projects to be explicitly enabled in {OCP} Monitoring. For more information, see link:https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/monitoring/configuring-user-workload-monitoring#configurable-monitoring-components_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]. link:https://issues.redhat.com/browse/GITOPS-6251[GITOPS-6251]
Original: * Before this update, monitoring support for workloads deployed in {OCP} namespaces, prefixed with `openshift-`, was available by default. Argo CD monitoring worked automatically only when deployed in {OCP} managed namespaces. With this update, monitoring support for Argo CD deployed in non-{OCP} namespaces requires monitoring for user-defined projects to be explicitly enabled in {OCP} Monitoring. For more information, see link:https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/monitoring/configuring-user-workload-monitoring#configurable-monitoring-components_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]. link:https://issues.redhat.com/browse/GITOPS-6251[GITOPS-6251]
Revised: * Before this update, monitoring support for workloads didn't require any configuraion by default. Argo CD monitoring worked automatically only when deployed in any namespaces. With this update, monitoring support for Argo CD deployed in non-{OCP} namespaces requires user-workload monitoring enabled in {OCP}. For more information, see link:https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/monitoring/configuring-user-workload-monitoring#configurable-monitoring-components_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]. link:https://issues.redhat.com/browse/GITOPS-6251[GITOPS-6251]
Original: * Before this update, Argo CD components, such as, `server`, `repo-server`, and `application-controller`, could crash when accessing the Redis instance due to network or DNS instabilities within the cluster. This issue stemmed from a race condition in the `go-redis` client library when multiple connections in a connection pool call the `dial hook` function. With this update, this issue is fixed. This update resolves the issue by integrating an updated `go-redis` client library that eliminates race conditions during `dial hook` function calls. It also improves the handling and recovery from network and DNS errors, ensuring greater stability for Argo CD components. link:https://issues.redhat.com/browse/GITOPS-6287[GITOPS-6287]
Revised: * Before this update, you might have experienced crashes in the Argo CD components, such as, `server`, `repo-server`, and `application-controller`, when accessing the Redis instance due to network or DNS instabilities within the cluster. These crashes occured from a race condition in the `go-redis` client library when multiple connections in a connection pool call the `dial hook` function. With this update, integrating an updated `go-redis` client library that eliminates race conditions during `dial hook` function calls resolves the issue, and improves the handling and recovery from network and DNS errors, ensuring greater stability for Argo CD components. link:https://issues.redhat.com/browse/GITOPS-6287[GITOPS-6287]
Original: * Before this update, upgrading the {gitops-title} Operator to v1.15.1 raised a health check error that prevented Red Hat Advanced Cluster Management (ACM) policies from syncing. This update fixes the issue by adding a missing nil check to `.status.placement` for *Policy*. link:https://issues.redhat.com/browse/GITOPS-6664[GITOPS-6664]
Revised: * Before this update, upgrading the {gitops-title} Operator to v1.15.1 raised a health check error that prevented {rh-rhacm-first} policies from syncing. With this update, adding a missing nil check to `.status.placement` for *Policy* resolves the issue. link:https://issues.redhat.com/browse/GITOPS-6664[GITOPS-6664]
Original: * Before this update, when `.spec.source.targetRevision` was set to an annotated Git tag, Argo CD treated resource drift as needing reconciliation. This caused manual changes on the cluster to be reverted, despite self-healing being disabled. This behavior was inconsistent with that of lightweight tags. With this update, Argo CD now handles annotated and lightweight tags consistently. When `selfHeal` is set to `false`, manual changes to live resources are no longer reverted, even if you are using an annotated Git tag as the source. link:https://issues.redhat.com/browse/GITOPS-6150[GITOPS-6150]
Revised: * Before this update, when `.spec.source.targetRevision` was set to an annotated Git tag, Argo CD treated resource drift as needing reconciliation and reverted the manual changes on the cluster, despite self-healing being disabled. This behavior was inconsistent with that of lightweight tags. With this update, when `selfHeal` is set to `false`, manual changes to live resources are no longer reverted, even if you are using an annotated Git tag as the source, and Argo CD now handles annotated and lightweight tags consistently.  link:https://issues.redhat.com/browse/GITOPS-6150[GITOPS-6150]
Original: * Before this update, user-workload monitoring support for workloads did not require any configuration by default. Argo CD monitoring worked automatically when deployed in any namespace. With this update, monitoring support for Argo CD deployed in non-{OCP} namespaces requires user-workload monitoring to be enabled in {OCP}. For more information, see link:https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/monitoring/configuring-user-workload-monitoring#configurable-monitoring-components_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]. link:https://issues.redhat.com/browse/GITOPS-6251[GITOPS-6251]
Revised: * Before this update, Argo CD monitoring worked automatically when deployed in any namespace and user-workload monitoring support for workloads did not require any manual configuration.  With this update, if you deploy Argo CD in a non-{OCP} namespace, you must enable user-workload monitoring in {OCP}. For more information, see link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/monitoring/configuring-user-workload-monitoring#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]. link:https://issues.redhat.com/browse/GITOPS-6251[GITOPS-6251]
Original: A vTPM device also protects virtual machines by storing secrets without physical hardware. {VirtProductName} supports persisting vTPM device state by using Persistent Volume Claims (PVCs) for VMs. You must specify the storage class to be used by the PVC by setting the `vmStateStorageClass` attribute in the `HyperConverged` custom resource (CR):
Revised: Similarly, the default storage class for the cluster has the annotation `storageclass.kubernetes.io/is-default-class` set to "true". To find this storage class, run the following command:
Original: Before installing {product-title}, you must configure the network properly to ensure that the edge subnets containing the remote nodes can reach the subnet containing the control plane nodes and receive traffic from the control plane too.
Revised: It is crucial that the install-time network configuration of the nodes makes them have their definitive node IP and that the nodes don't temporarily get any different node IP during their installation. As an example, if a node is to be configured with a bonded interface, their individual interfaces mustn't be assigned any different from node IP during the node setup.
Original: * *Secondary networks*: Act as additional, non-default networks for a pod. Secondary networks provide separate interfaces dedicated to specific traffic types or purposes. Only pod traffic that is explicitly configured to use a secondary network is routed through its interface.
Revised: * *Secondary networks*: Act as secondary, non-default networks for a pod. Secondary networks provide separate interfaces dedicated to specific traffic types or purposes. Only pod traffic that is explicitly configured to use a secondary network is routed through its interface.
Original: You can define an additional network based on the available CNI plugins and attach one or more of these networks to your pods. You can define more than one additional network for your cluster depending on your needs. This gives you flexibility when you configure pods that deliver network functionality, such as switching or routing.
For a complete list of supported CNI plugins, see xref:additional-networks-provided_understanding-multiple-networks["Additional networks in {product-title}"].
== Usage scenarios for an additional network
Revised: == Usage scenarios for a secondary network
Original: You can define an additional network based on the available CNI plugins and attach one or more of these networks to your pods. You can define more than one additional network for your cluster depending on your needs. This gives you flexibility when you configure pods that deliver network functionality, such as switching or routing.
For a complete list of supported CNI plugins, see xref:additional-networks-provided_understanding-multiple-networks["Additional networks in {product-title}"].
== Usage scenarios for an additional network
You can use an additional network in situations where network isolation is needed, including data plane and control plane separation. Isolating network traffic is useful for the following performance and security reasons:
Revised: You can use a secondary network, also known as a _secondary network_, in situations where network isolation is needed, including data plane and control plane separation. Isolating network traffic is useful for the following performance and security reasons:
Original: <4> Optional parameter that when set to `true` leads to the creation of a `veth` endpoint with a `state: down` configuration in the container. If set to `false`, you cannot use the IP address management (IPAM) CNI plugin.
Revised: <4> Optional: When set to `true` a `veth` endpoint with a `state: down` configuration is created in the container. If set to `false`, you cannot use the IP address management (IPAM) CNI plugin.
Original: When updating {istio} using the `RevisionBased` strategy, you can upgrade by more than one minor version at a time. The {SMProductName} Operator creates a new `IstioRevision` resource for each change to the ``.spec.version` field and deploys a corresponding control plane instance. To migrate workloads to the new control plane, set the `istio.io/rev` label on the namespace to match the name of the `IstioRevision` resource, and then restart the workloads.
Revised: When updating {istio} using the `RevisionBased` strategy, you can upgrade by more than one minor version at a time. The {SMProductName} Operator creates a new `IstioRevision` resource for each change to the `.spec.version` field and deploys a corresponding control plane instance. To migrate workloads to the new control plane, set the `istio.io/rev` label on the namespace to match the name of the `IstioRevision` resource, and then restart the workloads.
Original: [id="preparing-to-update-istio-control-plane-with-inplace_{context}"]
= Preparing to update Istio control plane with InPlace strategy
You can configure the {istio} control plane and workloads for the `InPlace` update strategy. When using the `InPlace` strategy, the `IstioRevision` resource created by the {SMProduct} Operator always uses the same name as the `{istio}` resource.
Revised: This section is not part of the update process. You can skip this installation if the cluster already includes an {istio} deployment.
Original: [id="preparing-to-update-istio-control-plane-with-inplace_{context}"]
= Preparing to update Istio control plane with InPlace strategy
You can configure the {istio} control plane and workloads for the `InPlace` update strategy. When using the `InPlace` strategy, the `IstioRevision` resource created by the {SMProduct} Operator always uses the same name as the `{istio}` resource.
Revised: You can skip this installation procedure if the cluster already includes an {istio} deployment.
Original: * There is a known issue when the grandmaster clock (T-GM) transitions to the Locked state too soon. This happens before the Digital Phase-Locked Loop (DPLL) completes its transition to the `Locked-HO-Acquired` state, and after the Global Navigation Satellite Systems (GNSS) time source is restored.
Revised: * When the grandmaster clock (T-GM) transitions to the Locked state too soon, an issue occurs. The issue happens before the Digital Phase-Locked Loop (DPLL) completes its transition to the `Locked-HO-Acquired` state, and after the Global Navigation Satellite Systems (GNSS) time source is restored.
Original: * Previously, the Single Root I/O Virtualization (SR-IOV) virtual function (VF) did not revert any unexpected value changes to the maximum transmission unit (MTU) value when a pod was deleted. This issue occurred if the is the application inside the pod had its MTU value changed; in turn, the pod would also have its MTU value changed. With this release, the SR-IOV Container Network Interface (CNI) now reverts any unexpected MTU value changes to the original value so that this issue no longer exists. (link:https://issues.redhat.com/browse/OCPBUGS-54392[*OCPBUGS-54392*])
Revised: * Previously, the Single Root I/O Virtualization (SR-IOV) virtual function (VF) did not revert any unexpected value changes to the maximum transmission unit (MTU) value when a pod was deleted. This issue occurred if the application inside the pod had its MTU value changed; in turn, the pod would also have its MTU value changed. With this release, the SR-IOV Container Network Interface (CNI) now reverts any unexpected MTU value changes to the original value so that this issue no longer exists. (link:https://issues.redhat.com/browse/OCPBUGS-54392[*OCPBUGS-54392*])
Original: * There is a known issue when the grandmaster clock (T-GM) transitions to the Locked state too soon. This happens before the Digital Phase-Locked Loop (DPLL) completes its transition to the `Locked-HO-Acquired` state, and after the Global Navigation Satellite Systems (GNSS) time source is restored.
Revised: * Previously, when you attempted to create a validating webhook for a resource that was managed by the `oauth` API server, the validating webhook was not created. This issue occurred because of a communication issue with the `oauth` API server and the data plane. With this release, a Konnectivity proxy sidecar has been added to bridge communications between the `oauth` API server and the data plane so that you can now create a validating webhook for any resource that the `oauth` API server manages.  (link:https://issues.redhat.com/browse/OCPBUGS-54841[*OCPBUGS-54841*])
Revised: * Previously, a User Datagram Protocol (UDP) packet that was larger than the maximum transmission unit (MTU) value set for the cluster could not be sent to the endpoint of the packet by using a service. With this release, the pod IP address is used instead of the service IP address regardless of the packet size, so that the UDP packet can be sent to the endpoint. (link:https://issues.redhat.com/browse/OCPBUGS-50579[*OCPBUGS-50579*])
Revised: * Previously, you could add white space to {aws-first} tag names, but the installation program did not support them. As a result, the installation program produced an `ERROR failed to fetch Metadata` message. With this release, the regular expression for {aws-short} tags validates any tag name that has white space so that the installation program accepts these tags. (link:https://issues.redhat.com/browse/OCPBUGS-46375[*OCPBUGS-46375*])
Original: *  In the bootstrap phase of the installation process, the transport layer security (TLS) between the `metal3` `httpd` server and the node's Baseboard Management Controller (BMC) is enabled by default in {product-title} 4.18 and later. The `httpd` server is on port 6183 instead of port 6180 when TLS is enabled. Disable the TLS setting by adding 'disableVirtualMediaTLS: true' to the Provisioning custom resource (CR) file that is created on the disk. (link:https://issues.redhat.com/browse/OCPBUGS-39404[OCPBUGS-39404])
Revised: * In the bootstrap phase of the installation process, the Transport Layer Security (TLS) between the `metal3` `httpd` server and the node's Baseboard Management Controller (BMC) is enabled by default in {product-title} 4.18 and later. The `httpd` server is on port 6183 instead of port 6180 when TLS is enabled. Disable the TLS setting by adding 'disableVirtualMediaTLS: true' to the Provisioning custom resource (CR) file that is created on the disk. (link:https://issues.redhat.com/browse/OCPBUGS-39404[OCPBUGS-39404])
Original: * Previously, the Prometheus remote-write proxy configuration was not correctly applied to the Prometheus user workload custom resource (CR), which caused communication and data collection problems in the cluster. With this release, the user workload monitoring (UWM) Prometheus configurations, including user workload Prometheus, correctly inherits the proxy settings from the cluster proxy resource. (link:https://issues.redhat.com/browse/OCPBUGS-38655[OCPBUGS-38655])
Revised: * Previously, the Prometheus remote-write proxy configuration was not correctly applied to the Prometheus user workload custom resource (CR), which caused communication and data collection problems in the cluster. With this release, the user workload monitoring (UWM) Prometheus configurations, including user workload Prometheus, correctly inherit the proxy settings from the cluster proxy resource. (link:https://issues.redhat.com/browse/OCPBUGS-38655[OCPBUGS-38655])
Original: * Previously, when running Red Hat Enterprise Linux CoreOS (RHCOS) in an active environment, the `rpm-ostree-fix-shadow-mode.service` that used to run caused the `rpm-ostree-fix-shadow-mode.service` to fail. With this release, the `rpm-ostree-fix-shadow-mode.service` does not activate when RHCOS does not run from an installed environment. (link:https://issues.redhat.com/browse/OCPBUGS-41625[OCPBUGS-41625])
Revised: * Previously, when running {op-system-first} in an active environment, the `rpm-ostree-fix-shadow-mode.service` that used to run caused the `rpm-ostree-fix-shadow-mode.service` to fail. With this release, the `rpm-ostree-fix-shadow-mode.service` does not activate when {op-system} does not run from an installed environment. (link:https://issues.redhat.com/browse/OCPBUGS-41625[OCPBUGS-41625])
Original: * Previously, an incorrect component import in `SimpleSelect.tsx` caused an undefined function `r` in `react-dom.production.min.js`. This component caused error messages on the *Dashboards* and *Metrics* pages related to dropdown lists. With this release, the dropdown lists on the affected pages function correctly, eliminating the error message. (link:https://issues.redhat.com/browse/OCPBUGS-42845[OCPBUGS-42845])
Revised: * Previously, an incorrect component import in the `SimpleSelect.tsx` file caused an undefined `r` function in the `react-dom.production.min.js` file. This component caused error messages on the *Dashboards* and *Metrics* pages related to dropdown lists. With this release, the dropdown lists on the affected pages function correctly. (link:https://issues.redhat.com/browse/OCPBUGS-42845[OCPBUGS-42845])
Original: * Previously, an error in the image pull secret controller's secret token rotation logic caused a temporary, invalid token for authentication, which caused disruptions in the image pull process. With this release, the updated image pull secret controller guarantees a smooth and continuous image pull process, because it eliminates the period when the token is not valid while the token rotates. (link:https://issues.redhat.com/browse/OCPBUGS-54304[OCPBUGS-54304])
Revised: * Previously, an error in the rotation logic of the image pull secret controller's secret token caused a temporary, invalid token for authentication. As a consequence, the image pull process was disrupted. With this release, the updated image pull secret controller eliminates the period when the token is not valid while the token rotates. As a result, the image pull process is smooth and continuous. (link:https://issues.redhat.com/browse/OCPBUGS-54304[OCPBUGS-54304])