SPLAT-2653: Add OLM v1 File-Based Catalog support and deployment manifests #99
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,6 +1,3 @@ | ||
| .git | ||
| bin | ||
| *.test | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -33,31 +33,50 @@ This is distinct from `openshift-region` / `openshift-zone`. Topology tags descr | |
| ## Getting Started | ||
|
|
||
| ### Prerequisites | ||
| - OpenShift Container Platform 4.18+ or 5.0+ (or Kubernetes v1.30.0+) | ||
| - `cluster-admin` privileges | ||
| - OpenShift CLI (`oc`) or `kubectl` | ||
| - Container tool (`podman` or `docker`) | ||
| - Go v1.25.0+ (for local development) | ||
|
|
||
| ### Installation via OLM v1 (Recommended) | ||
|
|
||
| On OpenShift 4.18+ and 5.0+, the operator is installed via Operator Lifecycle Manager v1 (OLM v1) using `ClusterCatalog` and `ClusterExtension`: | ||
|
|
||
| 1. **Deploy the File-Based Catalog:** | ||
| ```bash | ||
| oc apply -f config/samples/olmv1/cluster_catalog.yaml | ||
| ``` | ||
|
|
||
| 2. **Deploy the Operator Extension:** | ||
| ```bash | ||
| oc apply -f config/samples/olmv1/cluster_extension.yaml | ||
| ``` | ||
|
Comment on lines
+53
to
+54
There was a problem hiding this comment. 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win 🔎 Supported by static analysis🏁 Script executed: #!/bin/bash
set -eu
printf '%s\n' '--- repository knowledge files ---'
find /tmp/coderabbit-repo-knowledge/openshift-vcf-migration-operator-6934011c -type f -name '*.md' -print | sort
printf '%s\n' '--- README lines 35-65 ---'
cat -n README.md | sed -n '35,65p'
printf '%s\n' '--- OLM v1 sample files ---'
find config/samples/olmv1 -maxdepth 2 -type f -print | sort
printf '%s\n' '--- ClusterExtension manifest ---'
cat -n config/samples/olmv1/cluster_extension.yamlRepository: openshift/vcf-migration-operator Length of output: 2204 🏁 Script executed: #!/bin/bash
set -eu
printf '%s\n' '--- repository-wide conventions ---'
cat /tmp/coderabbit-repo-knowledge/openshift-vcf-migration-operator-6934011c/conventions/repo-wide.md
printf '%s\n' '--- catalog manifest ---'
cat -n config/samples/olmv1/cluster_catalog.yaml
printf '%s\n' '--- install documentation references ---'
rg -n -C 4 'OLM v1|ClusterExtension|ClusterCatalog|installNamespace|ServiceAccount|RoleBinding|openshift-vcf-migration|namespace' docs/install.md README.md config deploy bundle 2>/dev/null || true
printf '%s\n' '--- relevant tracked files ---'
git ls-files | rg '(^|/)(bundle|config|deploy|docs)/|(^|/)Makefile$' | head -150Repository: openshift/vcf-migration-operator Length of output: 50390 🏁 Script executed: #!/bin/bash
set -eu
printf '%s\n' '--- install sequence ---'
cat -n docs/install.md | sed -n '23,90p'
printf '%s\n' '--- bundle manifest names ---'
find bundle/manifests -maxdepth 1 -type f -printf '%f\n' | sort
printf '%s\n' '--- CSV install strategy and permissions ---'
rg -n -C 8 'installStrategy|permissions:|clusterPermissions:|serviceAccountName|deploymentName|create namespace|ServiceAccount|RoleBinding|ClusterRoleBinding' bundle/manifests/vcf-migration-operator.clusterserviceversion.yaml config/manifests/bases/vcf-migration-operator.clusterserviceversion.yaml
printf '%s\n' '--- bundle metadata ---'
cat -n bundle/metadata/annotations.yamlRepository: openshift/vcf-migration-operator Length of output: 10548 🌐 Web query:
💡 Result: In OpenShift 4.18, OLM v1 introduces the ClusterExtension API to manage cluster extensions, including Operators using the registry+v1 bundle format [1][2]. Key aspects of OLM v1 regarding installation, namespaces, and security are as follows: 1. Namespace and ServiceAccount: While the ClusterExtension custom resource (CR) includes a namespace field (which designates the namespace where the extension's namespace-scoped resources are applied) [3][4] and a serviceAccount field, the serviceAccount field is deprecated and ignored by the operator-controller [3]. OLM v1 is a single-tenant system where the operator-controller operates with cluster-admin privileges, effectively delegating trust to users with write access to ClusterExtension objects [3]. 2. RBAC Management: Because OLM v1 does not use the provided service account to install extensions, administrators must ensure the necessary RBAC permissions are defined to allow the operator-controller to manage the extension [5][6]. You must determine the required permissions by analyzing the extension's bundle manifests, specifically the ClusterServiceVersion (CSV) [5][7]. This includes: - RBAC for the installation service account to create/manage the extension's CRDs, deployments, services, and config maps [6]. - RBAC to grant the extension controller's service account the permissions declared in the CSV's spec.install.permissions and spec.install.clusterPermissions [5][6]. 3. Install Strategy: The ClusterServiceVersion (CSV) continues to use an InstallStrategy to define how the Operator is deployed [8][9]. When installing an Operator as a cluster extension in OLM v1, the bundle must use the registry+v1 format [1][7]. The operator-controller parses the CSV's install strategy (typically deployment-based) to understand the runtime requirements, such as the deployments and the associated permissions needed for the operator to function correctly [5][9]. In summary, the OLM v1 operator-controller handles the installation using its own high-privilege service account, while administrators must pre-configure the necessary RBAC to allow the controller to manage the specific resources defined within the bundle's CSV [3][5][6]. Citations:
🌐 Web query:
💡 Result: In OLM v1, because the Operator Controller does not have inherent permission to install extensions, it must be provided with a dedicated ServiceAccount that possesses the necessary permissions to manage the extension's resources [1]. To derive these permissions for a ClusterExtension, you must examine the contents of the extension's bundle image [1]. The bundle contains: 1. The manifests for all resources (e.g., CRDs, Deployments, Secrets) that the extension will manage [1]. 2. A ClusterServiceVersion (CSV) which explicitly details the permission requirements for the extension's own controller service account [1]. The ServiceAccount used by OLM v1 to install the extension requires sufficient RBAC permissions to [1]: - Create and manage the extension's CustomResourceDefinitions (CRDs). - Create and manage all resources bundled within the extension (e.g., Services, ConfigMaps, Deployments). - Create and manage the extension controller's ServiceAccount. - Create and manage the necessary Role, RoleBinding, ClusterRole, and ClusterRoleBinding resources required by the extension controller's ServiceAccount. - Create and manage the extension controller's Deployment. Essentially, the installer ServiceAccount acts with the authority to perform all actions defined within the bundle's manifests, including granting the extension's own controller the specific permissions specified in the CSV's spec.install.clusterPermissions (for cluster-scoped) and spec.install.permissions (for namespace-scoped) fields [1]. Citations: 🌐 Web query:
💡 Result: In the OLMv1 operator-controller, the spec.serviceAccount field within the ClusterExtension resource is deprecated and completely ignored [1][2]. OLMv1 has shifted to a single-tenant architecture where the operator-controller operates with cluster-admin privileges [1][2]. Consequently, the controller now uses its own service account for all cluster interactions, effectively eliminating the previous requirement for users to provide a specific ServiceAccount for extension installation and management [1][2][3]. Key details regarding this change include: - Deprecation Status: The spec.serviceAccount field is marked as deprecated in the API with the godoc convention and will be removed in a future release [1][2]. - System Behavior: Setting this field has no functional impact; it is ignored by the controller [1][4]. - Developer Warnings: To assist in the transition, the system includes a ValidatingAdmissionPolicy that emits a warning when spec.serviceAccount is defined in a ClusterExtension manifest [2][3]. - Documentation Changes: Documentation and guides previously referencing the derivation or use of a service account for ClusterExtensions have been deprecated or removed to reflect this move to cluster-admin scope [3][5]. Users should rely on the operator-controller's default cluster-admin permissions for managing extensions, rather than attempting to configure separate service accounts for them [1][2][3]. Citations:
Create the target namespace before applying the The README does not create 🤖 Prompt for AI AgentsSource: MCP tools |
||
|
|
||
| 3. **Verify Installation:** | ||
| ```bash | ||
| oc get clusterextension vcf-migration-operator | ||
| oc get pods -n openshift-vcf-migration | ||
| ``` | ||
|
|
||
| For detailed instructions, step-by-step walkthrough, and configuration examples, see [Installing VCF Migration Operator with OLM v1](docs/install.md). | ||
|
|
||
| --- | ||
|
|
||
| ## Local Development | ||
|
|
||
| ### Deploying Directly on Cluster (Non-OLM Dev Mode) | ||
|
|
||
| **Build and push the operator image:** | ||
|
|
||
| ```sh | ||
| make operator-image operator-push IMG=<some-registry>/vcf-migration-operator:tag | ||
| ``` | ||
|
|
||
| **Install CRDs and Deploy Manager:** | ||
|
|
||
| ```sh | ||
| make install | ||
| make deploy IMG=<some-registry>/vcf-migration-operator:tag | ||
| ``` | ||
|
|
||
|
|
@@ -66,30 +85,19 @@ privileges or be logged in as admin. | |
|
|
||
| **Create instances of your solution** | ||
|
|
||
| Apply the sample migration CRs from `config/samples/`: | ||
|
|
||
| ```sh | ||
| kubectl apply -k config/samples/ | ||
| ``` | ||
|
|
||
| ### To Uninstall Local Dev Deployment | ||
|
|
||
| **Delete instances and undeploy:** | ||
|
|
||
| ```sh | ||
| kubectl delete -k config/samples/ | ||
| make uninstall | ||
| make undeploy | ||
| ``` | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,30 @@ | ||
| # The builder image is expected to contain /bin/opm (with serve subcommand) | ||
| FROM registry.redhat.io/openshift4/ose-operator-registry-rhel9:v4.18 as builder | ||
|
|
||
| # Copy FBC root into image at /configs and pre-populate serve cache | ||
| COPY catalog /configs | ||
| RUN ["/bin/opm", "serve", "/configs", "--cache-dir=/tmp/cache", "--cache-only"] | ||
|
|
||
| FROM registry.redhat.io/openshift4/ose-operator-registry-rhel9:v4.18 | ||
|
|
||
| # Configure the entrypoint and command | ||
| ENTRYPOINT ["/bin/opm"] | ||
| CMD ["serve", "/configs", "--cache-dir=/tmp/cache"] | ||
|
|
||
| COPY LICENSE /licenses/license.txt | ||
| COPY --from=builder /configs /configs | ||
| COPY --from=builder /tmp/cache /tmp/cache | ||
|
|
||
| # Set FBC-specific label for the location of the FBC root directory in the image | ||
| LABEL operators.operatorframework.io.index.configs.v1=/configs | ||
| LABEL com.redhat.component="VCF Migration Operator Catalog" | ||
| LABEL distribution-scope="public" | ||
| LABEL name="vcf-migration/vcf-migration-operator-catalog" | ||
| LABEL release="0.0.1" | ||
| LABEL version="0.0.1" | ||
| LABEL cpe="cpe:/a:redhat:vcf_migration_operator:0.1::el9" | ||
| LABEL url="https://github.com/openshift/vcf-migration-operator" | ||
| LABEL vendor="Red Hat, Inc." | ||
| LABEL description="File-based catalog for the VCF Migration Operator." | ||
| LABEL summary="File-based catalog for the VCF Migration Operator." | ||
| LABEL io.k8s.display-name="VCF Migration Operator Catalog" |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,8 @@ | ||
| apiVersion: olm.operatorframework.io/v1 | ||
| kind: ClusterCatalog | ||
| metadata: | ||
| name: vcf-migration-operator-catalog | ||
| spec: | ||
| sourceType: Image | ||
| image: registry.ci.openshift.org/origin/vcf-migration-operator-catalog:latest | ||
| priority: 0 | ||
|
Comment on lines
+5
to
+8
There was a problem hiding this comment. 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win Align the OLM v1 manifests and installation examples with the required schemas.
📍 Affects 2 files
🤖 Prompt for AI Agents |
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,8 @@ | ||
| apiVersion: olm.operatorframework.io/v1 | ||
| kind: ClusterExtension | ||
| metadata: | ||
| name: vcf-migration-operator | ||
| spec: | ||
| packageName: vcf-migration-operator | ||
| channel: dev-preview | ||
| installNamespace: openshift-vcf-migration |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Regenerate the bundle before rendering the catalog.
make catalog-build VERSION=0.0.2writes a channel entry forvcf-migration-operator.v0.0.2, but it renders the existingbundledirectory. If that directory still containsv0.0.1,opm validatefails because the channel references a missing bundle. Makecatalog-generatedepend onbundle.Proposed fix
📝 Committable suggestion
🤖 Prompt for AI Agents