OSDOCS-20474:Update the z-stream RNs for 4.21.23#114547
Conversation
|
@tedaveryredhat: This pull request references OSDOCS-20474 which is a valid jira issue. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
🤖 Thu Jul 02 15:50:27 - Prow CI generated the docs preview: |
| [id="zstream-4-21-23-fixed-issues_{context}"] | ||
| == Fixed issues | ||
|
|
||
| * Before this update, the Cluster Ingress Operator (CIO) hardcoded the OLM catalog source name (`redhat-operators`) when managing the OSSM subscription for Gateway API. In disconnected environments, the catalog source had a different name, and the CIO unconditionally overwrote it. As a consequence, the Gateway API installation failed in disconnected and air-gapped environments because the OSSM subscription pointed to a catalog source that did not exist. With this release, the dependency on OLM catalog sources is removed entirely because the OLM-based OSSM installation is replaced with the Sail Library, which installs Istio directly through embedded Helm charts. As a result, the Gateway API does not require a catalog source and works in disconnected environments without workarounds. (link:https://issues.redhat.com/browse/OCPBUGS-86040[OCPBUGS-78330]) |
There was a problem hiding this comment.
🤖 [error] RedHat.TermsErrors: Use 'hard-coded' rather than 'hardcoded'. For more information, see RedHat.TermsErrors.
|
|
||
| * Before this update, the Cluster Ingress Operator (CIO) depended on the Marketplace capability to install OSSM through OLM for the Gateway API. On clusters where the Marketplace capability was disabled, such as disconnected clusters that cannot reach external catalog sources, the CIO could not create or manage the OLM subscription and the Istio control plane never started. As a consequence, the Gateway API did not function on these clusters. When the GatewayClass was created, the `istiod-openshift-gateway` pod did not start. With this release, the OLM-based OSSM installation is replaced with the Sail Library, which installs Istio directly through embedded Helm charts. As a result, the dependency on the Marketplace capability is removed and the Gateway API works on disconnected clusters and other environments without the Marketplace capability, provided that the required container images are mirrored to an accessible registry. (link:https://issues.redhat.com/browse/OCPBUGS-85550[OCPBUGS-85550]) | ||
|
|
||
| * Before this update, the Cluster Ingress Operator (CIO) installed the OpenShift Service Mesh (OSSM) operator through OLM to provide Gateway API support. and pinned OSSM to a specific version using the `startingCSV` parameter and manual install plan approval. As a consequence, after the OSSM was already installed, the OLM ignored the `startingCSV` parameter and resolved upgrades to the channel head, which generated install plans that the CIO never approved because the version did not match. The OSSM z-stream upgrades were then blocked, which prevented CVE fixes from being delivered to clusters using the Gateway API. With this release, the OLM-based OSSM installation is replaced with the Sail Library, which installs Istio directly through embedded Helm charts. The dependency on OLM for the Gateway API is removed and clusters that are upgraded from the OLM-based path are automatically migrated to the Sail Library during the z-stream upgrade. As a result, OSSM and Istio version management is not blocked by OLM and the CVE fixes can be shipped. (link:https://issues.redhat.com/browse/OCPBUGS-88295[OCPBUGS-88295]) |
There was a problem hiding this comment.
🤖 [error] Vale.Terms: Use 'Operators?' instead of 'operator'.
|
|
||
| * Before this update, when you clicked a status count, such as counts from error pods or not-ready nodes, from the *Overview* dashboard view, the resource list page opened without applying the expected filter. As a consequence, all resources were displayed instead of only the resources that matched the selected status. With this update, clicking a status count opens a filtered list page that shows only the matching resources. (link:https://issues.redhat.com/browse/OCPBUGS-90553[OCPBUGS-90553]) | ||
|
|
||
| * Before this update, during parallel deployments of Single Node OpenShift (SNO), specifically with hypervisor-based SNOs, some systems would hang in the middle of the deployment due to a race condition involving the BareMetalHost (BMH) custom resource. The SNO was never powered on by metal3 after virtual media was attached. As a consequence, parallel deployments at scale (10+ nodes) had approximately 80% success rate, with the remaining nodes requiring manual intervention to patch the `online` field to `true` for the impacted BMH custom resources. With this release, the race condition in the BMH power-on process has been resolved. As a result, parallel SNO deployments successfully power on all nodes without manual intervention, even at scale. (link:https://issues.redhat.com/browse/OCPBUGS-90554[OCPBUGS-90554]) |
There was a problem hiding this comment.
🤖 [error] Vale.Avoid: Avoid using 'Single Node OpenShift'.
|
|
||
| * Before this update, when you clicked a status count, such as counts from error pods or not-ready nodes, from the *Overview* dashboard view, the resource list page opened without applying the expected filter. As a consequence, all resources were displayed instead of only the resources that matched the selected status. With this update, clicking a status count opens a filtered list page that shows only the matching resources. (link:https://issues.redhat.com/browse/OCPBUGS-90553[OCPBUGS-90553]) | ||
|
|
||
| * Before this update, during parallel deployments of Single Node OpenShift (SNO), specifically with hypervisor-based SNOs, some systems would hang in the middle of the deployment due to a race condition involving the BareMetalHost (BMH) custom resource. The SNO was never powered on by metal3 after virtual media was attached. As a consequence, parallel deployments at scale (10+ nodes) had approximately 80% success rate, with the remaining nodes requiring manual intervention to patch the `online` field to `true` for the impacted BMH custom resources. With this release, the race condition in the BMH power-on process has been resolved. As a result, parallel SNO deployments successfully power on all nodes without manual intervention, even at scale. (link:https://issues.redhat.com/browse/OCPBUGS-90554[OCPBUGS-90554]) |
There was a problem hiding this comment.
🤖 [error] Vale.Avoid: Avoid using 'SNO'.
|
|
||
| * Before this update, when you clicked a status count, such as counts from error pods or not-ready nodes, from the *Overview* dashboard view, the resource list page opened without applying the expected filter. As a consequence, all resources were displayed instead of only the resources that matched the selected status. With this update, clicking a status count opens a filtered list page that shows only the matching resources. (link:https://issues.redhat.com/browse/OCPBUGS-90553[OCPBUGS-90553]) | ||
|
|
||
| * Before this update, during parallel deployments of Single Node OpenShift (SNO), specifically with hypervisor-based SNOs, some systems would hang in the middle of the deployment due to a race condition involving the BareMetalHost (BMH) custom resource. The SNO was never powered on by metal3 after virtual media was attached. As a consequence, parallel deployments at scale (10+ nodes) had approximately 80% success rate, with the remaining nodes requiring manual intervention to patch the `online` field to `true` for the impacted BMH custom resources. With this release, the race condition in the BMH power-on process has been resolved. As a result, parallel SNO deployments successfully power on all nodes without manual intervention, even at scale. (link:https://issues.redhat.com/browse/OCPBUGS-90554[OCPBUGS-90554]) |
There was a problem hiding this comment.
🤖 [error] Vale.Avoid: Avoid using 'SNO'.
| [id="zstream-4-21-23-updating_{context}"] | ||
| == Updating | ||
|
|
||
| To update an {product-title} 4.21 cluster to this latest release, see xref:../updating/updating_a_cluster/updating-cluster-cli.adoc#updating-cluster-cli[Updating a cluster using the CLI]. |
There was a problem hiding this comment.
🤖 [error] OpenShiftAsciiDoc.NoXrefInModules: Do not include xrefs in modules, only assemblies (exception: release notes modules).
|
@tedaveryredhat: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
Version(s):
4.21
Issue:
https://redhat.atlassian.net/browse/OSDOCS-20474
Link to docs preview:
Additional information:
4.21.23 MR: https://gitlab.cee.redhat.com/hybrid-platforms/art/ocp-shipment-data/-/merge_requests/626
ART Dashboard: https://art-dash.engineering.redhat.com/dashboard/release/openshift-4.21?page=1