Add metadata generation docs & update release docs

Author: darkowlzz

README.md

@@ -23,10 +23,10 @@ for more information.
 
 ## Setup/Development
 
-1. Install [operator-sdk](https://github.com/operator-framework/operator-sdk/tree/master#quick-start).
-2. Run `operator-sdk generate k8s` if there's a change in api type.
-3. Build operator container with `operator-sdk build storageos/cluster-operator:<tag>`
-4. Apply the manifests in `deploy/` to install the operator
+1. Build operator container image with `make image/cluster-operator`. Publish or
+  copy this container image to an existing k8s cluster to make it available
+  for use within the cluster.
+2. Apply the manifests in `deploy/` to install the operator
    * Apply `namespace.yaml` to create the `storageos-operator` namespace.
    * Apply `service_account.yaml`, `role.yaml` and `role_binding.yaml` to create
     a service account and to grant all the permissions.
@@ -53,7 +53,11 @@ make image/cluster-operator OPERATOR_IMAGE=storageos/cluster-operator:test
 
 This builds all the components and copies the binaries into the same container.
 
-After creating a resource, query the resource:
+For any changes related to Operator Lifecycle Manager(OLM), update
+`deploy/storageos-operators.configmap.yaml` and run `make metadata-update` to
+automatically update all the CRD, CSV and package files.
+
+After creating a StorageOSCluster resource, query the resource:
 
 ```bash
 $ kubectl get storageoscluster

deploy/olm/README.md

@@ -0,0 +1,21 @@
+## csv-rhel/
+
+This directory contains all the CSV files for rhel releases.
+
+## storageos/
+
+This directory contains all the CSV files for community operator releases. It
+also contains CRD and package files. This directory is also used to create a
+diff and submit a PR to the community operator repo for publishing new
+release. rhel releases uses the CRD and package files from this directory.
+
+## olm.sh
+
+This script contains helper functions to setup OLM in a cluster, install
+the storageos operator and install storageos. Also includes scripts to
+uninstallation everything it installs.
+
+
+## community-changes.yaml, rhel-changes.yaml, package-changes.yaml
+
+These files are update scripts for the yaml files used by yq yaml processor.

deploy/olm/csv-rhel/README.md

@@ -10,9 +10,16 @@ change, a new CSV with incremented version must be created.
 ## Release Instructions
 
 To create a new release:
-1. Update `metadata.annotations.containerImage` and deployment image with the
-new operator container image and `spec.version` to the new release version
-number in `storageos.clusterserviceversion.yaml`.
+1. Update `metadata.name` with new version name,
+`metadata.annotations.containerImage` and
+`spec.install.spec.deployments[0].spec.template.spec.containers[0].image` with
+the new operator container image, and `spec.version` to the new release version
+number in `deploy/olm/rhel-changes.yaml`. Run `make metadata-update` to generate
+`storageos.clusterserviceversion.yaml`.
+Any other change in the CSV file must be made in
+`deploy/storageos-operators.configmap.yaml` and regenerate all the metadata
+files.
+
 2. Run `make metadata-zip` from the root of the project to generate a metadata
 zip file at `/build/_output/storageos-olm-metadata.zip`. This file can be
 directly uploaded to the rhel operator metadata scanner for a new release.
@@ -23,4 +30,4 @@ the repo to keep a record of the releases.
 ## Testing
 
 Run `make metadata-bundle-lint` from the root of the project to create a
-metadata bundle and lint it before submitting a new release.
+metadata bundle at `build/_output/` and lint it before submitting a new release.

deploy/olm/storageos/README.md

@@ -9,17 +9,21 @@ releases have the release version in the file name
 be modified because releases are versioned and can't be rereleased. For any
 change, a new CSV with incremented version must be created.
 
+## Release Instructions
+
+Update `metadata.name` with new version number,
+`metadata.annotations.containerImage` and
+`spec.install.spec.deployments[0].spec.template.spec.containers[0].image` with
+the new operator container image, and `spec.version` to the new release version
+number in `deploy/olm/community-changes.yaml`. Run `make metadata-update` to
+generate `storageos.clusterserviceversion.yaml`.
+
+Any other change in the CSV file must be made in
+`deploy/storageos-operators.configmap.yaml` and regenerate all the metadata
+files.
+
 ## Testing
 
 Run `make olm-lint` from the project root to lint all the file in this
 directory. A lint must be performed before submitting a new release to the
 operatorhub.
-
-For e2e tests, ensure that any change in `storageos.clusterserviceversion.yaml`,
-`storageos.package.yaml` and all the crd.yaml files are copied to
-[`/deploy/storageos-operators.configmap`](/deploy/storageos-operators.configmap).
-The configmap is used as a catalog source in the OLM e2e tests.
-
-__NOTE__: With more tooling, we should be able to generate a gRPC catalog source
-using the files in this directory directly, without maintaining a separate
-configmap.

docs/release-process.md

@@ -14,11 +14,16 @@ The release requires
 `deploy/olm/csv-rhel/storageos.v<version>.clusterserviceversion.yaml` and
 `deploy/olm/storageos/storageos.v<version>.clusterserviceversion.yaml` to be
 checked-in before `version` is tagged. These files should have the container
-image set to tag `version`. Once tagged, these containers are published using
-`scripts/deploy.sh`. rhel build is triggered at the same time to publish a new
-container in rhel container registry. The metadata zip for rhel release is
-generated and attached to the github release automatically. This file can then
-be submitted to the rhel metadata scanner for a new rhel operator release.
+image set to tag `version`. Update `community-changes.yaml`, `rhel-changes.yaml`
+and `package-changes.yaml` files with the new versions and run
+`make metadata-update` from project root to automatically update all the CSV and
+package files with new versions and images. Once tagged, these containers are
+published using `scripts/deploy.sh`. rhel build is triggered at the same time to
+publish a new container in rhel container registry. The metadata zip for rhel
+release is generated and attached to the github release automatically. This file
+can then be submitted to the rhel metadata scanner for a new rhel operator
+release.
+
 `scripts/create-pr.sh` creates a new PR to update the community-operator with
 the new release. Once the PR is merged, a new version is released at
 operatorhub.io.