|
1 | 1 | # Overview |
2 | 2 |
|
3 | | -These notes are a summary of the more in-depth, internal documentation [here](https://app.nuclino.com/Stackable/Engineering/Certification-Process-a8cf57d0-bd41-4d56-b505-f59af4159a56). |
| 3 | +This is a short guide on how to build and test OLM manifests for the Stackable operators. |
4 | 4 |
|
5 | | -# Prerequisites |
| 5 | +The workflow contains these steps: |
6 | 6 |
|
7 | | -- an [OpenShift](https://developers.redhat.com/products/openshift-local/overview) cluster with the `stackable-operators` namespace |
8 | | -- [opm](https://github.com/operator-framework/operator-registry/) |
9 | | -- docker and kubectl |
10 | | -- `kubeadmin` access: once logged in to an openshift cluster a secret is needed |
11 | | -``` |
12 | | -export KUBECONFIG=~/.kube/config |
13 | | -oc create secret generic kubeconfig --from-file=kubeconfig=$KUBECONFIG --namespace stackable-operators |
14 | | -``` |
15 | | -- [tkn](https://github.com/tektoncd/cli) |
16 | | -- a secret for `pyxis_api_key`: a token giving access to Redhat Connect |
17 | | -- a secret for `github-api-token`: a token giving access to the RH repo |
| 7 | +1. Generate OLM Manifests |
| 8 | +2. Build and Install Bundles |
| 9 | +3. Test Operators |
18 | 10 |
|
19 | | -# Deployment |
| 11 | +# Prerequisites |
20 | 12 |
|
21 | | -Stackable operators can be deployed to Openshift in one of three ways: |
| 13 | +- An [OpenShift](https://developers.redhat.com/products/openshift-local/overview) or an [OKD](https://okd.io/) cluster |
| 14 | +- [operator-sdk](https://github.com/operator-framework/operator-sdk/) |
| 15 | +- [docker](https://docs.docker.com/engine/install/) |
| 16 | +- [kubectl](https://github.com/kubernetes/kubectl) |
22 | 17 |
|
23 | | -- Helm: either natively, or by using stackablectl |
24 | | -- Operator Catalog |
25 | | -- Certified Operators |
| 18 | +# Generate OLM Manifests |
26 | 19 |
|
27 | | -The latter two require an operator to be deployed to an Openshift cluster, from where the operator (and its dependencies, if these have been defined) can be installed from the console UI. Both pathways use version-specific manifest files which are created in the [Stackable repository](https://github.com/stackabletech/openshift-certified-operators) that is forked from [here](https://github.com/redhat-openshift-ecosystem/certified-operators). These manifests are largely based on the templates used by helm, with the addition of Openshift-specific items (such as a ClusterServiceVersion manifest). |
| 20 | +Before generating OLM manifests for an operator ensure that you have checked out the correct branch or tag |
| 21 | +in the corresponding operator repository. |
28 | 22 |
|
29 | | -## Build the bundle |
| 23 | +The OLM manifests are usually generated into the [OpenShift Certified Operators Repository](https://github.com/stackabletech/openshift-certified-operators) |
| 24 | +which is the source of the certification process. |
30 | 25 |
|
31 | | -An operator bundle and catalog can be built and deployed using the `build-bundle.sh` script e.g. |
| 26 | +## Secret and Listener Operators |
32 | 27 |
|
33 | | -``` |
34 | | -./olm/build-bundles.sh -r 23.4.1 -b secret-23.4.1 -o secret-operator -d |
| 28 | +The manifest generation for these two operators is only partially automated. |
| 29 | +You start with the script below and then manually update the cluster service version. |
| 30 | +To generate the manifests for the secret operator version 24.11.1, run: |
| 31 | + |
| 32 | +```bash |
| 33 | +./olm/build-manifests.sh -r 24.11.1 \ |
| 34 | + -c $HOME/repo/stackable/openshift-certified-operators \ |
| 35 | + -o $HOME/repo/stackable/secret-operator |
35 | 36 | ``` |
36 | 37 |
|
37 | 38 | Where: |
38 | 39 | - `-r <release>`: the release number (mandatory). This must be a semver-compatible value to patch-level e.g. 23.1.0. |
39 | | -- `-b <branch>`: the branch name (mandatory) in the (stackable forked) openshift-certified-operators repository. |
40 | | -- `-o <operator-name>`: the operator name (mandatory) e.g. airflow-operator. |
41 | | -- `-d <deploy>`: optional flag for catalog deployment. |
| 40 | +- `-c <manifest folder>`: the output folder for the manifest files |
| 41 | +- `-o <operator-dir>`: directory of the operator repository |
42 | 42 |
|
43 | | -The script creates a catalog specific to an operator. A catalog can contain bundles for multiple operators, but a 1:1 deployment makes it easier to deploy and test operators independently. Testing with a deployed catalog is essential as the certification pipeline should only be used for stable operators, and a certified operator can only be changed if a new version is specified. |
| 43 | +Similarly for the listener operator run: |
44 | 44 |
|
45 | | -## Use the CI pipeline |
46 | | - |
47 | | -### Testing |
| 45 | +```bash |
| 46 | +./olm/build-manifests.sh -r 24.11.1 \ |
| 47 | + -c $HOME/repo/stackable/openshift-certified-operators \ |
| 48 | + -o $HOME/repo/stackable/listener-operator |
| 49 | +``` |
48 | 50 |
|
49 | | -This should either be called from the stackable-utils root folder, or the `volumeClaimTemplateFile` path should be changed accordingly. |
| 51 | +## All Other Operators |
50 | 52 |
|
| 53 | +```bash |
| 54 | +./olm/build-manifests.py \ |
| 55 | + --openshift-versions 'v4.14-v4.16' \ |
| 56 | + --release 24.11.1 \ |
| 57 | + --skips 24.7.0 \ |
| 58 | + --repo-operator ~/repo/stackable/hbase-operator |
51 | 59 | ``` |
52 | | -export GIT_REPO_URL=https://github.com/stackabletech/openshift-certified-operators |
53 | | -export BUNDLE_PATH=operators/stackable-commons-operator/23.4.1 |
54 | | -export LOCAL_BRANCH=commons-23.4.1 |
55 | | -
|
56 | | -tkn pipeline start operator-ci-pipeline \ |
57 | | - --namespace stackable-operators \ |
58 | | - --param git_repo_url=$GIT_REPO_URL \ |
59 | | - --param git_branch=$LOCAL_BRANCH \ |
60 | | - --param bundle_path=$BUNDLE_PATH \ |
61 | | - --param env=prod \ |
62 | | - --param kubeconfig_secret_name=kubeconfig \ |
63 | | - --workspace name=pipeline,volumeClaimTemplateFile=olm/templates/workspace-template.yml \ |
64 | | - --showlog |
| 60 | + |
| 61 | +See `./olm/build-manifests.py --help` for the description of command line arguments. |
| 62 | + |
| 63 | +# Build and Install Bundles |
| 64 | + |
| 65 | +Operator bundles are needed to test the OLM manifests but *not needed* for the operator certification. |
| 66 | + |
| 67 | +## Build bundles |
| 68 | + |
| 69 | +To build operator bundles run: |
| 70 | + |
| 71 | +```bash |
| 72 | +./olm/build-bundles.sh \ |
| 73 | + -c $HOME/repo/stackable/openshift-certified-operators \ |
| 74 | + -r 24.11.1 \ |
| 75 | + -o listener \ |
| 76 | + -d |
65 | 77 | ``` |
66 | 78 |
|
67 | | -### Certifying |
| 79 | +Where: |
| 80 | +- `-r <release>`: the release number (mandatory). This must be a semver-compatible value to patch-level e.g. 23.1.0. |
| 81 | +- `-c <manifest folder>`: the folder with the input OLM manifests for the bundle |
| 82 | +- `-o <operator-name>`: the operator name (mandatory) e.g. "airflow" |
| 83 | +- `-d`: Optional. Deploy the bundle. Default: false. |
| 84 | + |
| 85 | +N.B. This action will push the bundles to `oci.stackable.tech` and requires that the user be logged in first. This can be done by copying the CLI token from the Harbor UI once you are logged in there (see under "Profile"), and then using this as the password when prompted on entering `docker login oci.stackabe.tech`. |
| 86 | +## Operator upgrades |
68 | 87 |
|
69 | | -This callout is identical to the previous one, with the addition of the last two parameters `upstream_repo_name` and `submit=true`: |
| 88 | +To test operator upgrades run `operator-sdk run bundle-upgrade` like this: |
70 | 89 |
|
| 90 | +```bash |
| 91 | +operator-sdk run bundle-upgrade \ |
| 92 | + oci.stackable.tech/sandbox/listener-bundle:24.11.2 \ |
| 93 | + --namespace stackable-operators |
71 | 94 | ``` |
72 | | -export GIT_REPO_URL=https://github.com/stackabletech/openshift-certified-operators |
73 | | -export BUNDLE_PATH=operators/stackable-commons-operator/23.4.1 |
74 | | -export LOCAL_BRANCH=commons-23.4.1 |
75 | | -
|
76 | | -tkn pipeline start operator-ci-pipeline \ |
77 | | - --namespace stackable-operators \ |
78 | | - --param git_repo_url=$GIT_REPO_URL \ |
79 | | - --param git_branch=$LOCAL_BRANCH \ |
80 | | - --param bundle_path=$BUNDLE_PATH \ |
81 | | - --param env=prod \ |
82 | | - --param kubeconfig_secret_name=kubeconfig \ |
83 | | - --workspace name=pipeline,volumeClaimTemplateFile=olm/templates/workspace-template.yml \ |
84 | | - --showlog \ |
85 | | - --param upstream_repo_name=redhat-openshift-ecosystem/certified-operators \ |
86 | | - --param submit=true |
| 95 | + |
| 96 | +# Test Operators |
| 97 | + |
| 98 | +To run the integration tests against an operator installation (ex. listener): |
| 99 | + |
| 100 | +```bash |
| 101 | +./scripts/run-tests --skip-operator listener --test-suite openshift |
87 | 102 | ``` |
88 | 103 |
|
89 | | -A successful callout will result in a PR being opened in the Redhat repository, from where progress can be tracked. |
| 104 | +Here we skip the installation of the listener operator by the test suite because this is already installed |
| 105 | +as an operator bundle. |
| 106 | + |
| 107 | +## Bundle cleanup |
90 | 108 |
|
| 109 | +To remove an operator bundle and all associated objects, run: |
| 110 | + |
| 111 | +```bash |
| 112 | +operator-sdk cleanup listener-operator --namespace stackable-operators |
| 113 | +``` |
0 commit comments