Merge pull request #93794 from lahinson/osdocs-13478-hcp-4.19-rns

[OSDOCS-13478]: Adding stub topic for HCP 4.19 RNs

Author: lahinson

_unused_topics/hosted-control-planes-release-notes.adoc

@@ -0,0 +1,117 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="hosted-control-planes-release-notes"]
+include::_attributes/common-attributes.adoc[]
+= {hcp-capital} release notes
+:context: hosted-control-planes-release-notes
+
+toc::[]
+
+Release notes contain information about new and deprecated features, changes, and known issues.
+
+[id="hcp-4-19-release-notes_{context}"]
+== {hcp-capital} release notes for {product-title} 4.19
+
+With this release, {hcp} for {product-title} 4.19 is available. {hcp-capital} for {product-title} 4.19 supports {mce} version 2.9.
+
+[id="hcp-4-19-new-features-and-enhancements_{context}"]
+=== New features and enhancements
+
+
+[id="bug-fixes-hcp-rn-4-19_{context}"]
+=== Bug fixes
+
+* Previously, when an IDMS or ICSP in the management OpenShift cluster defined a source that pointed to registry.redhat.io or registry.redhat.io/redhat, and the mirror registry did not contain the required OLM catalog images, provisioning for the `HostedCluster` resource stalled due to unauthorized image pulls. As a consequence, the `HostedCluster` resource was not deployed, and it remained blocked, where it could not pull essential catalog images from the mirrored registry.
++
+With this release, if a required image cannot be pulled due to authorization errors, the provisioning now explicitly fails. The logic for registry override is improved to allow matches on the root of the registry, such as registry.redhat.io, for OLM CatalogSource image resolution. A fallback mechanism is also introduced to use the original `ImageReference` if the registry override does not yield a working image.
++
+As a result, the `HostedCluster` resource can be deployed successfully, even in scenarios where the mirror registry lacks the required OLM catalog images, as the system correctly falls back to pulling from the original source when appropriate. (link:https://issues.redhat.com/browse/OCPBUGS-56492[OCPBUGS-56492])
+
+
+[id="known-issues-hcp-rn-4-19_{context}"]
+=== Known issues
+
+* If the annotation and the `ManagedCluster` resource name do not match, the {mce} console displays the cluster as `Pending import`. The cluster cannot be used by the {mce-short}. The same issue happens when there is no annotation and the `ManagedCluster` name does not match the `Infra-ID` value of the `HostedCluster` resource.
+
+* When you use the {mce} console to add a new node pool to an existing hosted cluster, the same version of {product-title} might appear more than once in the list of options. You can select any instance in the list for the version that you want.
+
+* When a node pool is scaled down to 0 workers, the list of hosts in the console still shows nodes in a `Ready` state. You can verify the number of nodes in two ways:
+
+** In the console, go to the node pool and verify that it has 0 nodes.
+** On the command-line interface, run the following commands:
+
+*** Verify that 0 nodes are in the node pool by running the following command:
++
+[source,terminal]
+----
+$ oc get nodepool -A
+----
+
+*** Verify that 0 nodes are in the cluster by running the following command:
++
+[source,terminal]
+----
+$ oc get nodes --kubeconfig
+----
+
+*** Verify that 0 agents are reported as bound to the cluster by running the following command:
++
+[source,terminal]
+----
+$ oc get agents -A
+----
+
+* When you create a hosted cluster in an environment that uses the dual-stack network, you might encounter the following DNS-related issues:
+
+** `CrashLoopBackOff` state in the `service-ca-operator` pod: When the pod tries to reach the Kubernetes API server through the hosted control plane, the pod cannot reach the server because the data plane proxy in the `kube-system` namespace cannot resolve the request. This issue occurs because in the HAProxy setup, the front end uses an IP address and the back end uses a DNS name that the pod cannot resolve.
+** Pods stuck in the `ContainerCreating` state: This issue occurs because the `openshift-service-ca-operator` resource cannot generate the `metrics-tls` secret that the DNS pods need for DNS resolution. As a result, the pods cannot resolve the Kubernetes API server.
+To resolve these issues, configure the DNS server settings for a dual stack network.
+
+* On the Agent platform, the {hcp} feature periodically rotates the token that the Agent uses to pull ignition. As a result, if you have an Agent resource that was created some time ago, it might fail to pull ignition. As a workaround, in the Agent specification, delete the secret of the `IgnitionEndpointTokenReference` property then add or modify any label on the Agent resource. The system re-creates the secret with the new token.
+
+* If you created a hosted cluster in the same namespace as its managed cluster, detaching the managed hosted cluster deletes everything in the managed cluster namespace including the hosted cluster. The following situations can create a hosted cluster in the same namespace as its managed cluster:
+
+** You created a hosted cluster on the Agent platform through the {mce} console by using the default hosted cluster cluster namespace.
+** You created a hosted cluster through the command-line interface or API by specifying the hosted cluster namespace to be the same as the hosted cluster name.
+
+* When you use the console or API to specify an IPv6 address for the `spec.services.servicePublishingStrategy.nodePort.address` field of a hosted cluster, a full IPv6 address with 8 hextets is required. For example, instead of specifying `2620:52:0:1306::30`, you need to specify `2620:52:0:1306:0:0:0:30`.
+
+[id="hcp-tech-preview-features_{context}"]
+=== General Availability and Technology Preview features
+
+Some features in this release are currently in Technology Preview. These experimental features are not intended for production use. For more information about the scope of support for these features, see link:https://access.redhat.com/support/offerings/techpreview[Technology Preview Features Support Scope] on the Red{nbsp}Hat Customer Portal.
+
+[IMPORTANT]
+====
+For {ibm-power-title} and {ibm-z-title}, you must run the control plane on machine types based on 64-bit x86 architecture, and node pools on {ibm-power-title} or {ibm-z-title}.
+====
+
+.{hcp-capital} GA and TP tracker
+[cols="4,1,1,1",options="header"]
+|===
+|Feature |4.17 |4.18 |4.19
+
+|{hcp-capital} for {product-title} using non-bare-metal agent machines
+|Technology Preview
+|Technology Preview
+|Technology Preview
+
+|{hcp-capital} for an ARM64 {product-title} cluster on {aws-full}
+|General Availability
+|General Availability
+|General Availability
+
+|{hcp-capital} for {product-title} on {ibm-power-title}
+|General Availability
+|General Availability
+|General Availability
+
+|{hcp-capital} for {product-title} on {ibm-z-title}
+|General Availability
+|General Availability
+|General Availability
+
+|{hcp-capital} for {product-title} on {rh-openstack}
+|Developer Preview
+|Developer Preview
+|Technology Preview
+|===