openshift · michaelryanpeter · Mar 14, 2025
diff --git a/extensions/arch/catalogd.adoc b/extensions/arch/catalogd.adoc
@@ -11,11 +11,6 @@ include::snippets/technology-preview.adoc[]
 
 {olmv1-first} uses the catalogd component and its resources to manage Operator and extension catalogs.
 
-[IMPORTANT]
-====
-include::snippets/olmv1-known-issue-private-registries.adoc[]
-====
-
 include::modules/olmv1-about-catalogs.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources

diff --git a/extensions/catalogs/creating-catalogs.adoc b/extensions/catalogs/creating-catalogs.adoc
@@ -11,11 +11,6 @@ include::snippets/technology-preview.adoc[]
 
 Catalog maintainers can create new catalogs in the file-based catalog format for use with {olmv1-first} on {product-title}.
 
-[IMPORTANT]
-====
-include::snippets/olmv1-known-issue-private-registries.adoc[]
-====
-
 include::modules/olm-creating-fb-catalog-image.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources

diff --git a/extensions/catalogs/fbc.adoc b/extensions/catalogs/fbc.adoc
@@ -11,11 +11,6 @@ include::snippets/technology-preview.adoc[]
 
 {olmv1-first} in {product-title} supports _file-based catalogs_ for discovering and sourcing cluster extensions, including Operators, on a cluster.
 
-[IMPORTANT]
-====
-include::snippets/olmv1-known-issue-private-registries.adoc[]
-====
-
 include::modules/olm-fb-catalogs.adoc[leveloffset=+1]
 
 include::modules/olm-fb-catalogs-structure.adoc[leveloffset=+1]

diff --git a/extensions/catalogs/rh-catalogs.adoc b/extensions/catalogs/rh-catalogs.adoc
@@ -11,9 +11,4 @@ include::snippets/technology-preview.adoc[]
 
 Red Hat provides several Operator catalogs that are included with {product-title} by default.
 
-[IMPORTANT]
-====
-include::snippets/olmv1-known-issue-private-registries.adoc[]
-====
-
 include::modules/olm-rh-catalogs.adoc[leveloffset=+1]
diff --git a/extensions/ce/managing-ce.adoc b/extensions/ce/managing-ce.adoc
@@ -13,11 +13,6 @@ After a catalog has been added to your cluster, you have access to the versions,
 
 You can manage extensions declaratively from the CLI using custom resources (CRs).
 
-[IMPORTANT]
-====
-include::snippets/olmv1-known-issue-private-registries.adoc[]
-====
-
 include::modules/olmv1-supported-extensions.adoc[leveloffset=+1]
 
 [role="_additional-resources"]

diff --git a/extensions/ce/upgrade-edges.adoc b/extensions/ce/upgrade-edges.adoc
@@ -13,11 +13,6 @@ When determining upgrade edges, also known as upgrade paths or upgrade constrain
 
 By supporting {olmv0} semantics, {olmv1} now honors the upgrade graph from catalogs accurately.
 
-[IMPORTANT]
-====
-include::snippets/olmv1-known-issue-private-registries.adoc[]
-====
-
 .Differences from original {olmv0} implementation
 
 * If there are multiple possible successors, {olmv1} behavior differs in the following ways:

diff --git a/extensions/index.adoc b/extensions/index.adoc
@@ -35,11 +35,6 @@ Earlier Technology Preview phases of {olmv1} introduced a new `Operator` API; th
 * The `Catalog` API, provided by the new catalogd component, serves as the foundation for {olmv1}, unpacking catalogs for on-cluster clients so that users can discover installable content, such as Kubernetes extensions and Operators. This provides increased visibility into all available Operator bundle versions, including their details, channels, and update edges.
 --
 +
-[IMPORTANT]
-====
-include::snippets/olmv1-known-issue-private-registries.adoc[]
-====
-+
 For more information, see xref:../extensions/arch/operator-controller.adoc#operator-controller[Operator Controller] and xref:../extensions/arch/catalogd.adoc#catalogd[Catalogd].
 
 

diff --git a/modules/olmv1-adding-a-catalog.adoc b/modules/olmv1-adding-a-catalog.adoc
@@ -9,12 +9,6 @@
 
 To add a catalog to a cluster, create a catalog custom resource (CR) and apply it to the cluster.
 
-
-[IMPORTANT]
-====
-include::snippets/olmv1-known-issue-private-registries.adoc[]
-====
-
 .Prerequisites
 
 // https://docs.asciidoctor.org/asciidoc/latest/directives/include-list-item-content/

diff --git a/modules/olmv1-creating-a-pull-secret-for-catalogd.adoc b/modules/olmv1-creating-a-pull-secret-for-catalogd.adoc
@@ -13,11 +13,6 @@ endif::[]
 
 include::snippets/olmv1-secure-registry-pull-secret.adoc[]
 
-[IMPORTANT]
-====
-include::snippets/olmv1-known-issue-private-registries.adoc[]
-====
-
 .Prerequisites
 
 * Login credentials for the secure registry

diff --git a/modules/olmv1-installing-an-operator.adoc b/modules/olmv1-installing-an-operator.adoc
@@ -9,12 +9,6 @@
 
 You can install an extension from a catalog by creating a custom resource (CR) and applying it to the cluster. {olmv1-first} supports installing cluster extensions, including {olmv0} Operators via the `registry+v1` bundle format, that are scoped to the cluster. For more information, see _Supported extensions_.
 
-
-[IMPORTANT]
-====
-include::snippets/olmv1-known-issue-private-registries.adoc[]
-====
-
 .Prerequisites
 
 * You have added a catalog to your cluster.

diff --git a/modules/olmv1-red-hat-catalogs.adoc b/modules/olmv1-red-hat-catalogs.adoc
@@ -13,19 +13,7 @@
 
 [IMPORTANT]
 ====
-
-* {empty}
-+
---
-include::snippets/olmv1-known-issue-private-registries.adoc[]
---
-
-* {empty}
-+
---
 include::snippets/olmv1-secure-registry-pull-secret.adoc[]
---
-
 ====
 
 .Example Red Hat Operators catalog

diff --git a/release_notes/ocp-4-17-release-notes.adoc b/release_notes/ocp-4-17-release-notes.adoc
@@ -96,17 +96,12 @@ Improved status conditions::
 In this release, {olmv1} includes improved status conditions and error messaging via the `ClusterExtension` API.
 
 [id="ocp-4-17-extensions-supported-extensions_{context}"]
-==== {olmv1} supported extensions and known issue
+==== {olmv1} supported extensions
 
 include::snippets/olmv1-tp-extension-support.adoc[]
 
 include::snippets/olmv1-operator-conditions-support.adoc[]
 
-[IMPORTANT]
-====
-include::snippets/olmv1-known-issue-private-registries.adoc[]
-====
-
 [id="ocp-4-17-edge-computing_{context}"]
 === Edge computing
 
@@ -2973,7 +2968,7 @@ $ oc adm release info 4.17.18 --pullspecs
 [id="ocp-4-17-18-bug-fixes_{context}"]
 ==== Bug fixes
 
-* Previously, the control plane Operator did not honor the set PROXY environment variables when it checked the API endpoint availability. With this release, the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-50596[*OCPBUGS-50596*]) 
+* Previously, the control plane Operator did not honor the set PROXY environment variables when it checked the API endpoint availability. With this release, the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-50596[*OCPBUGS-50596*])
 
 * Previously, when installing a cluster on {aws-first} in existing subnets that were located in edge zones, such as a AWS Local Zone or a Wavelength Zone, the `kubernetes.io/cluster/<InfraID>:shared` tag was missing in the subnet resources of the edge zone. With this release, a fix ensures that all subnets that are used in the `install-config.yaml` configuration file have the required tag. (link:https://issues.redhat.com/browse/OCPBUGS-49975[*OCPBUGS-49975*])
 
@@ -3052,11 +3047,11 @@ $ oc adm release info 4.17.16 --pullspecs
 
 * Previously, importing manifest lists could cause an API crash if the source registry returned an invalid sub-manifest result. With this update, the API flags an error on the imported tag instead of crashing. (link:https://issues.redhat.com/browse/OCPBUGS-49399[*OCPBUGS-49399*])
 
-* Previously, the Konnectivity proxy used by the `openshift-apiserver` in the control plane resolved registry names with cloud API suffixes on the control plane and then attempted to access them through the data plane. 
+* Previously, the Konnectivity proxy used by the `openshift-apiserver` in the control plane resolved registry names with cloud API suffixes on the control plane and then attempted to access them through the data plane.
 +
-A hosted cluster that used the no-egress feature in ROSA, and a container registry that was accessible through an Amazon Virtual Private Cloud (VPC) endpoint was created but failed to install because `imagestreams` that use the container registry did not resolve. With this release, the Konnectivity proxy resolves and routes hostnames consistently. (link:https://issues.redhat.com/browse/OCPBUGS-46465[*OCPBUGS-46465*]) 
+A hosted cluster that used the no-egress feature in ROSA, and a container registry that was accessible through an Amazon Virtual Private Cloud (VPC) endpoint was created but failed to install because `imagestreams` that use the container registry did not resolve. With this release, the Konnectivity proxy resolves and routes hostnames consistently. (link:https://issues.redhat.com/browse/OCPBUGS-46465[*OCPBUGS-46465*])
 
-* Previously, if you ran a build that required a trust bundle to access registries, it did not pick up the bundle configured in the cluster proxy. The builds failed if they referenced a registry required for a custom trust bundle. With this release, builds that require the trust bundle specified in the proxy configuration succeed, and the issue is resolved.  (link:https://issues.redhat.com/browse/OCPBUGS-45268[*OCPBUGS-45268*]) 
+* Previously, if you ran a build that required a trust bundle to access registries, it did not pick up the bundle configured in the cluster proxy. The builds failed if they referenced a registry required for a custom trust bundle. With this release, builds that require the trust bundle specified in the proxy configuration succeed, and the issue is resolved.  (link:https://issues.redhat.com/browse/OCPBUGS-45268[*OCPBUGS-45268*])
 
 * Previously, when you attempted to use the {hcp} CLI to create a {hcp} cluster, the installation failed because of a release image check on multi-arch images. With this release, an update to the {hcp} CLI codebase fixes the issue so that the release image check does not fail when checking for multi-arch images. (link:https://issues.redhat.com/browse/OCPBUGS-44927[*OCPBUGS-44927*])