OSDOCS#10370: Add OLMv1 4.18 RNs: features

release_notes/ocp-4-18-release-notes.adoc

@@ -80,6 +80,45 @@ For more information, see xref:../backup_and_restore/hibernating-cluster.adoc#hi
 [id="ocp-release-notes-extensions_{context}"]
 === Extensions ({olmv1})
 
+Operator Lifecycle Manager (OLM) has been included with {product-title} 4 since its initial release and has helped grow and enable a substantial ecosystem of solutions and advanced workloads running as Operators. {product-title} {product-version} introduces {olmv1}, the next-generation Operator Lifecycle Manager, as a General Availability feature, designed to improve how you manage Operators on {product-title}.
+
+Previously available as a Technology Preview feature only, this updated framework evolves many of the concepts that have been part of previous versions of {olmv0} by simplifying Operator management, enhancing secrutiy, and boosting reliability.
+
+[NOTE]
+====
+The documentation for {olmv1} exists as a stand-alone guide called xref:../extensions/index.adoc#olmv1-about[Extensions]. Previously, {olmv1} documentation was a subsection of the xref:../operators/index.adoc#operators-overview[Operators] guide, which otherwise documents the {olmv0} feature set.
+
+The updated location and guide name reflect a more focused documentation experience and aims to differentiate between {olmv1} and {olmv0}.
+====
+
+Simplified API::
+{olmv1} simplifies Operator management with a new, user-friendly API: xref:../extensions/arch/operator-controller.adoc#olmv1-clusterextension-api_operator-controller[the `ClusterExtension` object]. By managing Operators as integral extensions of the cluster, {olmv1} caters to the special lifecycle requirements of custom resource definition (CRDs). This design aligns more closely with Kubernetes principles, treating Operators, which consist of custom controllers and CRDs, as cluster-wide singletons. 
++
+{product-title} continues to give you access to the latest Operator packages, patches, and updates through default xref:../extensions/catalogs/rh-catalogs.adoc#rh-catalogs[Red Hat Operator catalogs]. With {olmv1}, you can install an Operator package by creating and applying a `ClusterExtension` API object in your cluster. By interacting with `ClusterExtension` objects, you can manage the lifecycle of Operator packages, quickly understand their status, and troubleshoot issues.
+
+Streamlined declarative workflows::
+Leveraging the simplified API, you can define your desired Operator states in a declarative way and, when integrating with tools like Git and Zero Touch Provisioning, let {olmv1} automatically maintain those states. This minimizes human error and unlocks a wider range of use cases.
+
+Uninterrupted operations with continuous reconciliation and optional rollbacks::
+{olmv1} enhances reliability through continuous reconciliation. Rather than relying on single attempts, {olmv1} proactively addresses Operator installation and update failures, automatically retrying until the issue is resolved. This eliminates the manual steps previously required, such as deleting `InstallPlan` API objects, and greatly simplifies the resolution of off-cluster issues, such as missing container images or catalog problems.
++
+In addition, {olmv1} provides optional rollbacks, allowing you to revert Operator version updates under specific conditions after carefully assessing any potential risks.
+
+Granular update control for deployments::
+With granular update control, you can select a specific Operator version or define a range of acceptable versions. For example, if you have tested and approved version `1.2.3` of an Operator in a stage environment, instead of hoping the latest version works just as well in production, you can use version pinning. By specifying `1.2.3` as the desired version, you can ensure that is the exact version that will be deployed for a safe and predictable update.
++
+Alternatively, automatic z-stream updates provide a seamless and secure experience by automatically applying security fixes without manual intervention, minimizing operational disruptions.
+
+Enhanced security with user-provided `ServiceAccount` objects::
+{olmv1} prioritizes security by minimizing its permission requirements and providing greater control over access. By using user-provided `ServiceAccount` objects for Operator lifecycle operations, {olmv1} access is restricted to only the necessary permissions, significantly reducing the control plane attack surface and improving overall security. In this way, {olmv1} adopts a least-privilege model to minimize the impact of a compromise.
+
+[id="ocp-4-18-extensions-supported-extensions_{context}"]
+==== {olmv1} supported extensions and known issue
+
+include::snippets/olmv1-tp-extension-support.adoc[]
+
+include::snippets/olmv1-operator-conditions-support.adoc[]
+
 [id="ocp-release-notes-edge-computing_{context}"]
 === Edge computing
 

snippets/olmv1-operator-conditions-support.adoc

@@ -1,6 +1,7 @@
 // Text snippet included in the following modules:
 //
 // * modules/olmv1-supported-extensions.adoc
+// * release_notes/ocp-4-18-release-notes.adoc (enteprise-4.18 branch only)
 // * release_notes/ocp-4-17-release-notes.adoc (enterprise-4.17 branch only)
 // * release_notes/ocp-4-16-release-notes.adoc (enterprise-4.16 branch only)
 // * release_notes/ocp-4-15-release-notes.adoc (enterprise-4.15 branch only)

snippets/olmv1-tp-extension-support.adoc

@@ -1,6 +1,8 @@
 // Text snippet included in the following modules:
 //
 // * modules/olmv1-supported-extensions.adoc
+// * release_notes/ocp-4-18-release-notes.adoc (enteprise-4.18 branch only)
+// * release_notes/ocp-4-17-release-notes.adoc (enteprise-4.17 branch only)
 // * release_notes/ocp-4-16-release-notes.adoc (enteprise-4.16 branch only)
 // * release_notes/ocp-4-15-release-notes.adoc (enteprise-4.15 branch only)