Add olmv1 blog

content/blog/2025-08-11-olmv1-support-and-chart-dependencies.adoc

@@ -0,0 +1,174 @@
+---
+ date: 2025-08-11
+ title: Supporting the Latest Standards with Validated Patterns
+ summary: This post introduces how the Validated Patterns framework supports OLMv1, the new operator packaging standard 
+ author: Martin Jackson
+ blog_tags:
+ - patterns
+ - announce
+---
+:toc:
+:imagesdir: /images
+
+Open Source Technology is always evolving, and we need to be prepared to evolve with it. In OpenShift 4.18, Red Hat
+promoted the new OLMv1 packaging standard to General Availability. OLM is the Operator Lifecycle Manager, a vital
+component of OpenShift. Users generally do not interact with OLM as such, but they are familiar with how OpenShift
+offers Operators to install on clusters and OperatorHub - all of the operators advertized there are offered as OLM
+packages.
+
+Up until this point, Validated Patterns have only supported installation via OLMv0. OLMv1 uses the same packaging
+format, but places some restrictions on what the bundles can and cannot do. Further, OLMv1 requires a serviceAccount
+to explicitly be named to install the bundle. This required changes to one of the framework's key charts, and that in
+turn led to changes with how we manage our chart publication pipeline. This blog post will cover three topics:
+
+* Support for OLMv1 objects (ClusterExtensions) in the Validated Patterns Framework
+* Using the new vp-rbac chart with Validated Patterns
+* How our chart building pipeline had to change
+
+Please note that all of these changes are effective as of the publication of clustergroup chart version 0.9.30, so any
+new installation of any publicly maintained Validated Pattern after August 8, 2025 will be able to make use of these
+new features.
+
+== Support for OLMv1 (ClusterExtensions)
+
+Definitive explanations of what OLMv1 is can be found here: link:https://www.redhat.com/en/blog/announcing-olm-v1-next-generation-operator-lifecycle-management[Announcing OLM v1: Next-Generation Operator Lifecycle Management]. Detailed 
+information on how to create ClusterExtension objects can be found here: link:https://developers.redhat.com/articles/2025/06/02/manage-operators-clusterextensions-olm-v1[Manage operators as ClusterExtensions with OLM v1].
+
+OLMv1 introduces a completely new Kubernetes Kind, the ClusterExtension, which functions somewhat differently than the
+Subscription object that previous versions of OLM used. Further, OLMv1 requires the explicit use of a service account
+with which to install the operator bundle. OLMv1 is fairly restrictive in not allowing several previously common
+methods of declaring version constraints, but over time we expect more operator bundles will support being installed
+via OLMv1.
+
+OLMv1 objects are created by passing entries through the Subscriptions object. Each subscription may be an OLMv0 or
+OLMv1 object. The determination on which type of object to create is based on the presence of OLMv1 specific fields.
+If the object for the subscription contains a "channels", "upgradeConstraintPolicy" or "serviceAccount" key, an OLMv1
+ClusterExtension object will be created. Otherwise, the framework will create an OLMv0 Subscription. Existing code
+will continue to function as it has.
+
+Here is an example of a subscription object that will create an OLMv1 ClusterExtension:
+
+[source,yaml]
+----
+---
+  subscriptions:
+    quay-operator:
+      name: quay-operator
+      namespace: redhat-quay
+      channels: [ "stable-3.12" ]
+      serviceAccountName: quay-sa
+----
+
+The chart sees the "channels" key and the "serviceAccountName" key and knows that it should create an OLMv1 object
+based on that. The name becomes the OLMv1 PackageName. You may also specify a "version" key to pin the subscription
+to a specific version or range as described link:https://developers.redhat.com/articles/2025/06/02/manage-operators-clusterextensions-olm-v1#3__upgrade_a_clusterextension[here]. If you need it, the chart also understands and uses the
+"upgradeConstraintPolicy" key.
+
+Additionally, OLMv1 allows multiple channels to be added, so they key "channels" takes an array of channel names.
+
+The final difference is the serviceAccountName. OLMv1 now requires a service account name to install each operator.
+Before, the Validated Patterns framework did not have a mechanism to install serviceAccounts, roles, or role
+bindings early enough for them to be used to install operators. Several patterns had their own structures for
+adding these objects, but they were private to the patterns, or else not especially flexible and could not be 
+changed without effectively re-writing them. Since that chart had been published under the name "rbac" in our charts
+repository, we wrote a new chart that could be used by clustergroup, and could be included as a dependency in other
+charts as well.
+
+== Using vp-rbac
+
+The new vp-rbac chart is designed to provision serviceAccounts, roles, clusterRoles, and rolebindings. It was
+developed primarily to meet the needs of clustergroup for adding serviceAccounts to install operators with
+fine-grained access controls, but can be used for other serviceAccounts scenarios as well.
+
+The (simplest, though perhaps not the most secure) structure needed to install quay looks like this:
+
+[source,yaml]
+----
+vp-rbac:
+  serviceAccounts:
+    quay-sa:
+      namespace: redhat-quay
+      roleBindings:
+        clusterRoles:
+          - cluster-admin
+----
+
+The key ('quay-sa' in this case) becomes the name of the serviceAccount, and the namespace key is required.
+Rolebindings can be created for roles or clusterRoles; in this case we bind quay-sa to the (pre-existing)
+cluster-admin clusterRole. Rolebindings are always part of the serviceAccount structure for this chart.
+
+The chart also supports creating roles and clusterRoles, if you need to define custom ones. Roles and clusterRoles
+support multiple rules. Each rule may specify apiGroups, resources, and verbs. If a rule omits one of these keys,
+they each have defaults: apiGroups defaults to [ "'\*'" ] (which includes the empty or core apiGroup); resources
+similarly defaults to [ "'*'" ]; verbs defaults to [ 'get', 'list', 'watch' ] (that is, "read-only" permissions).
+
+Here is a more complete example of what can be done with the vp-rbac structure:
+
+[source,yaml]
+----
+vp-rbac:
+  serviceAccounts:
+    web-terminal-sa:
+      namespace: web-terminal
+      roleBindings:
+        clusterRoles:
+          - cluster-admin
+    test-admin:
+      namespace: aap-config
+      roleBindings:
+        clusterRoles:
+          - cluster-admin
+          - view-secrets-cms
+        roles:
+          - testrole
+  roles:
+    testrole:
+      namespace: aap-config
+      rules:
+        - apiGroups:
+            - '""'
+          resources:
+            - configmaps
+          verbs:
+            - "list"
+            - "watch"
+  clusterRoles:
+    view-secrets-cms:
+      rules:
+        - apiGroups:
+            - '""'
+          resources:
+            - secrets
+            - configmaps
+          verbs:
+            - "get"
+            - "list"
+            - "watch"
+----
+
+This structure allows the creation of structures as fine-grained as you may need, and also makes it straightforward
+to create a serviceAccount with admin just to experiment or as a proof-of-concept if you do not know exactly what
+permissions are actually needed.
+
+== Using vp-rbac
+
+You can add vp-rbac to your charts by declaring it as a dependency to your chart, like this (in Chart.yaml):
+
+[source,yaml]
+----
+dependencies:
+  - name: vp-rbac
+    version: "0.1.*"
+    repository: "https://charts.validatedpatterns.io"
+----
+
+We enhanced our chart-building pipeline to be able to resolve and include chart dependencies for the charts
+that we publish in link:https://charts.validatedpatterns.io[our chart repository].
+
+We may replace some of the RBACs that we create in the patterns framework with the vp-rbac chart, but we
+do not plan to do this for all of our charts as this might break backwards compatibility in some cases.
+
+== We Want Your Feedback!
+
+We are excited to offer support for OLMv1 fairly early in its adoption cycle; please feel free to give it a try!
+If you encounter any issues with the OLMv1 feature in clustergroup, please report them link:https://github.com/validatedpatterns/clustergroup-chart/issues[here]. Any issues witht the vp-rbac chart can be reported link:https://github.com/validatedpatterns/vp-rbac-chart/issues[here].