diff --git a/docs/ocp-release.md b/docs/ocp-release.md index 0fd4a51ce..d87234984 100644 --- a/docs/ocp-release.md +++ b/docs/ocp-release.md @@ -1,4 +1,14 @@ # Release process for OCP +* [ProdSec considerations](#prodsec-considerations) +* [Pin to a new Golang and K8S API version](#pin-to-a-new-golang-and-k8s-api-version) +* [Branching and creation of a new development streams](#branching-and-creation-of-a-new-development-stream) + * [Development stream for the Operator](#development-stream-for-the-operator) + * [Development stream for the FBC](#development-stream-for-the-fbc) + * [Create a new FBC fragment for a new OCP release](#create-a-new-fbc-fragment-for-a-new-ocp-release) +* [Release the operator (for OCP)](#release-process-for-ocp) +* [Publish a bundle in the OCP's OperatorHub's FBCs](#publish-a-bundle-in-the-ocps-operatorhubs-fbcs)\ +* [Example Release](#example-release) + ## ProdSec considerations If the release is a major version or introduced significant @@ -22,21 +32,6 @@ The issues will have to be remediated according to the timelines set in the stan If malware is detected, contact prodsec@redhat.com immediately. -## Create a new FBC fragment for a new OCP release - -The current approach is that for every new OCP release, we will have to: -1. Create New Konflux Application and Component for the FBC - https://gitlab.cee.redhat.com/releng/konflux-release-data/-/merge_requests/2515/diffs?commit_id=5af448016c0f5d65dd74ddffeafa27932fa9b252 -2. Create a new branch in this repo like `fbc-4.16`. E.g., `fbc-4.17` for OCP 4.17 -3. Update the tekton files on the new branch - https://github.com/openshift/multiarch-tuning-operator/pull/350/commits/cf23045ba70e4806efc3690ebd786b717075a25b -3. Create a new PR in https://gitlab.cee.redhat.com/releng/konflux-release-data/-/tree/main to add the new File Based Catalog (FBC) fragment to the ReleasePlanAdmission, based on - a. https://gitlab.cee.redhat.com/releng/konflux-release-data/-/blob/main/config/stone-prd-rh01.pg1f.p1/product/ReleasePlanAdmission/multiarch-tuning-ope/multiarch-tuning-operator-fbc-prod-index.yaml - b. https://gitlab.cee.redhat.com/releng/konflux-release-data/-/blob/main/config/stone-prd-rh01.pg1f.p1/product/ReleasePlanAdmission/multiarch-tuning-ope/multiarch-tuning-operator-fbc-staging-index.yaml - Example PR: https://gitlab.cee.redhat.com/releng/konflux-release-data/-/merge_requests/3039 -4. Adjust the BASE_IMAGE argument for the `build-args` parameter in the Konflux PipelineRun. -5. Adjust the graphs as needed in the branches. - ## Pin to a new Golang and K8S API version 1. Update go version in base images @@ -112,9 +107,10 @@ The PR in the repo may need to be paired with one in the Prow config: see https://github.com/openshift/release/pull/55728/commits/707fa080a66d8006c4a69e452a4621ed54f67cf6 as an example ## Branching and creation of a new development stream +### Development stream for the operator This is done at the beginning of a release cycle. -1. Create new branch off of main. For example v1.0, v0.9. +1. Create new branch off of main. For example v1.x, v1.0, v0.9. 2. Define a new Development Stream for the operator in the [Konflux cluster](https://gitlab.cee.redhat.com/releng/konflux-release-data).

Create a new directory @@ -127,7 +123,7 @@ This is done at the beginning of a release cycle. # multiarch-tuning-operator-/projectdevelopmentstream.yaml --- apiVersion: projctl.konflux.dev/v1beta1 - kind: ProjectDevelopmentStream + kind: ProjectDevelopmentStream metadata: name: multiarch-tuning-operator- spec: @@ -173,28 +169,80 @@ This is done at the beginning of a release cycle. - change the components to include ``

Run `build-manifests.sh` to generate auxiliary files. After making the changes, create a new pull request. +### Development stream for the FBC +This is done when a new OCP version is added. + +1. Define a new Development Stream for the operator in the [Konflux + cluster](https://gitlab.cee.redhat.com/releng/konflux-release-data).

+ Create a new directory + `tenants-config/cluster/stone-prd-rh01/tenants/multiarch-tuning-ope-tenant/_base/projectl.konflux.dev/projectdevelopmentstreams/fbc- `. + For instance, when the branch version is v4.18, replace the period (.) with a dash (-). Thus, would be formatted as v4-18. + Add two files to the directory `projectdevelopmentstream.yaml` and `kustomization.yaml`. + + ```yaml + # multiarch-tuning-operator-/projectdevelopmentstream.yaml + --- + apiVersion: projctl.konflux.dev/v1beta1 + kind: ProjectDevelopmentStream + metadata: + name: file-based-catalog- + spec: + + project: multiarch-tuning-operator + template: + name: file-based-catalog + values: + - name: version + # The version name, formatted without the 'v' prefix (e.g., '4.18' for version `v4.18') + value: + ``` + + ```yaml + # multiarch-tuning-operator-/kustomization.yaml + --- + kind: Kustomization + apiVersion: kustomize.config.k8s.io/v1beta1 + resources: + - ./projectdevelopmentstream.yaml + ``` + + Update `tenants-config/cluster/stone-prd-rh01/tenants/multiarch-tuning-ope-tenant/_base/kustomization.yaml` file to + include the newly added `projectdevelopmentstreams`.

+ Run `build-manifests.sh` to generate auxiliary files. +2. Update the `ReleasePlanAdmission` for both [multiarch-tuning-operator-fbc-staging-index.yaml](https://gitlab.cee.redhat.com/releng/konflux-release-data/-/blob/main/config/stone-prd-rh01.pg1f.p1/product/ReleasePlanAdmission/multiarch-tuning-ope/multiarch-tuning-operator-fbc-staging-index.yaml) and [multiarch-tuning-operator-fbc-prod-index.yaml](https://gitlab.cee.redhat.com/releng/konflux-release-data/-/blob/main/config/stone-prd-rh01.pg1f.p1/product/ReleasePlanAdmission/multiarch-tuning-ope/multiarch-tuning-operator-fbc-prod-index.yaml) by adding the new `fbc-` to `spec.applications`. +#### Create a new FBC fragment for a new OCP release +1. Create a new directory in [fbc branch](https://github.com/outrigger-project/multiarch-tuning-operator/tree/fbc) called `fbc-v4-x/catalog/multiarch-tuning-operator` + Copy contents from the most recent ocp versions `index.yaml` into the newly created directory's `index.yaml`.
+ Do not copy from fbc-v4-16 and do not change the contents of the yaml file. +3. Update the tekton files by adding a new `fbc-v4-x-pull-request.yaml` and `fbc-v4-x-push.yaml`

+4. Adjust the base-image argument for the `build-args` parameter in the Konflux PipelineRun. +5. Adjust the graphs as needed in the branches. + An example pr can be found [here](https://github.com/outrigger-project/multiarch-tuning-operator/pull/642) + ## Release the operator (for OCP) 1. Bump the operator version -To bump the operator version, run the following command: +To bump the operator version, run the following commands: ```shell make version VERSION=1.0.1 +./hack/bump-version.sh ``` -Also verify that no other references to the previous versions are present in the codebase. -If so, update hack/bump-version.sh to include any further patches required to update the version. + Verify that no other references to the previous versions are present in the codebase. +If so, update `hack/bump-version.sh` to include any further patches required to update the version. -2. When planning to release a new version (e.g. v1.0) or a patch version (e.g., v1.0.z), select a snapshot from the -corresponding Konflux application -and ensure all post-submit checks have successfully passed. -There are two ways to check if the snapshot contains the right images. +1. When planning to release a new version (e.g. v1.0) or a patch version (e.g., v1.0.z), select a snapshot from the +corresponding Konflux application. This snapshot should be on-push that has the latest commit we want to release. +Ensure all post-submit checks, pipeline tasks, and enterprise contract tests have successfully passed. +Log any warnings if they have occurred ([example](https://redhat-internal.slack.com/archives/C06ECDGH4LE/p1761098980898099?thread_ts=1760127394.479789&cid=C06ECDGH4LE)).

+Check if the snapshot contains the right images. There are two ways to do this. - Run `./hack/check-snapshots.sh` and skip to step 4 - Manually check with the following command and steps 2 and 3 - ```shell - oc get snapshots --sort-by .metadata.creationTimestamp -l pac.test.appstudio.openshift.io/event-type=push,appstudio.openshift.io/application=multiarch-tuning-operator- - ``` + ```shell + oc get snapshots --sort-by .metadata.creationTimestamp -l pac.test.appstudio.openshift.io/event-type=push,appstudio.openshift.io/application=multiarch-tuning-operator- + ``` 2. Look at the results of the tests for the commit reported in the snapshot: ```yaml # [ ... ] @@ -227,11 +275,8 @@ spec: find /tmp/operator_bundle -name "*.clusterserviceversion.yaml" -print yq '.spec.install.spec.deployments[0].spec.template.metadata.annotations."multiarch.openshift.io/image"' ``` -4. Get the new snapshot triggered by the build of the merge commit at the previous point and check the build pipeline for errors and warnings. -```shell -oc get snapshots --sort-by .metadata.creationTimestamp -l pac.test.appstudio.openshift.io/event-type=push,appstudio.openshift.io/application=multiarch-tuning-operator- -``` -5. Update the [allowed tags](https://gitlab.cee.redhat.com/releng/konflux-release-data/-/blob/main/config/stone-prd-rh01.pg1f.p1/product/ReleasePlanAdmission/multiarch-tuning-ope/multiarch-tuning-operator-1-0.yaml#L27-28) for the release plan admission + +4. Update the [allowed tags](https://gitlab.cee.redhat.com/releng/konflux-release-data/-/blob/main/config/stone-prd-rh01.pg1f.p1/product/ReleasePlanAdmission/multiarch-tuning-ope/multiarch-tuning-operator-1-0.yaml#L27-28) for the `ReleasePlanAdmission` ```yaml # ... defaults: @@ -242,36 +287,41 @@ defaults: # ... ``` 6. In [comet](https://comet.engineering.redhat.com/containers/repositories/6616582895a35187a06ba2ce) add the new tag in the content streams field -7. Create a new release for the operator +7. Create a new release for the operator. The description should come from the docs team. ```yaml apiVersion: appstudio.redhat.com/v1alpha1 kind: Release metadata: - generateName: release-1-0-0- + generateName: release-1-x-x>- namespace: multiarch-tuning-ope-tenant spec: - releasePlan: multiarch-tuning-operator-1-0-release-as-operator - snapshot: multiarch-tuning-operator-1-0-5lr4j + releasePlan: multiarch-tuning-operator-x-release-as-operator + snapshot: data: releaseNotes: type: RHEA - synopsis: Red Hat Multiarch Tuning 1.0.0 + synopsis: Red Hat Multiarch Tuning 1.x.x + issues: + fixed: + - id: MULTIARCH-xxxx + source: issues.redhat.com topic: >- - The 1.0.0 release of the Red Hat Multiarch Tuning Operator. - For more details, see [product documentation](https://docs.openshift.com/container-platform/4.17/post_installation_configuration/configuring-multi-arch-compute-machines/multiarch-tuning-operator.html). + The 1.x.x release of the Red Hat Multiarch Tuning Operator. + For more details, see product documentation in the references section. description: >- - The Red Hat Multiarch Tuning Operator can be used with OpenShift Container Platform. Enhancements: - - With this release, the Multiarch Tuning Operator supports custom network scenarios and cluster-wide custom registries configurations. - - With this release, you can identify pods based on their architecture compatibility by using the pod labels that the Operator adds to newly created pods. - - With this release, you can monitor the behavior of the Multiarch Tuning Operator by using the metrics and alerts registered in the cluster monitoring operator. - solution: >- + * List of features + Bug fixes: + * List of fixes + solution: | The Multiarch Tuning Operator optimizes workload management within multi-architecture clusters and in single-architecture clusters transitioning to multi-architecture environments. This Operator is available in the Red Hat Operators catalog that is included with OpenShift Container Platform. - For more details, see [product documentation](https://docs.openshift.com/container-platform/4.17/post_installation_configuration/configuring-multi-arch-compute-machines/multiarch-tuning-operator.html). + For more details, see product documentation in the references section. references: - - https://docs.openshift.com/container-platform/4.17/post_installation_configuration/configuring-multi-arch-compute-machines/multiarch-tuning-operator.html - - https://github.com/openshift/multiarch-tuning-operator + - https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/postinstallation_configuration/configuring-multi-architecture-compute-machines-on-an-openshift-cluster#multiarch-tuning-operator + - https://github.com/outrigger-project/multiarch-tuning-operator + - https://github.com/openshift/openshift-docs/blob/989810607bedb7d3c727fb55907355de2ba80af8/post_installation_configuration/configuring-multi-arch-compute-machines/multi-arch-tuning-operator-release-notes.adoc + - https://github.com/openshift/openshift-docs/blob/main/post_installation_configuration/configuring-multi-arch-compute-machines/multiarch-tuning-operator.adoc ``` 8. Watch the `status` of the `Release` Object or look in the Konflux UI to confirm that images and bundle were published as expected. Note that the peipeline is run in a different namespace (rhtap-releng-tenant). @@ -280,9 +330,10 @@ spec: Note: these steps need to be applied to each FBC 1. Download opm from https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/latest-4./ -1. Update the `fbc-4.x` branches to use the selected container image for both the bundle and operator. - Append the new package generated with the command below and set the nodes and upgrade edges in the related channel graph. - Example [commit](https://github.com/openshift/multiarch-tuning-operator/pull/341). +1. Update the `fbc-4.x` directories in the [fbc branch](https://github.com/outrigger-project/multiarch-tuning-operator/tree/fbc) to use the selected snapshot. + Append the rendered output of the snapshot to each `index.yaml`. There are two methods. + 2. Run `/hack/build-indexs.sh ` and `./hack/update-graph.sh ` + 3. Append the new package generated with the command below and set the nodes and upgrade edges in the related channel graph. ```shell opm render --output=yaml --migrate-level bundle-object-to-csv-metadata @@ -316,8 +367,9 @@ spec: url: https://github.com/openshift/multiarch-tuning-operator ``` + Regardless of the method commit the changes in a [pr](https://github.com/openshift/multiarch-tuning-operator/pull/54). -9. Get the new snapshot triggered by the build of the merge commit at the previous point and check the build pipeline for errors and warnings. +9. Get the new snapshots triggered by the build of the merge commit from the pr created in the previous step and check the build pipeline for errors and warnings. Document any warnings. ```shell oc get snapshots --sort-by .metadata.creationTimestamp -l pac.test.appstudio.openshift.io/event-type=push,appstudio.openshift.io/application=fbc-v4-x @@ -331,10 +383,10 @@ spec: apiVersion: appstudio.redhat.com/v1alpha1 kind: Release metadata: - generateName: manual-release- + generateName: manual-release-- namespace: multiarch-tuning-ope-tenant spec: - releasePlan: fbc-4-1x-release-as-fbc # fbc-v4-16-release-as-staging-fbc is available for a staging release + releasePlan: fbc-4-x-release-as-fbc # fbc-v4-16-release-as-staging-fbc is available for a staging release snapshot: fbc- # EOF ``` @@ -352,3 +404,39 @@ as expected. Note that the peipeline is run in a different namespace (rhtap-rele ``` Take the index image and replace the registry `registry-proxy.engineering.redhat.com/rh-osbs/iib` with `brew.registry.redhat.io`. The image to announce would look like `brew.registry.redhat.io/rh-osbs/iib:835019` + + +## Example Release +### Pre Development Work +Create the epic and tasks for the upcoming release these will help guide and document the steps to be taken for the release. +Remember to link the epics/stories related to this release. +The [tasks will differ](https://spaces.redhat.com/spaces/ENTMQMAAS/pages/151038604/Creating+a+new+micro+Z-stream+release) depending on what type of release it is (x/y/z stream). +Epics are [PLMPGM-3819](https://issues.redhat.com/browse/PLMPGM-3819) and +[PLMPGM-3872](https://issues.redhat.com/browse/PLMPGM-3872) + +Follow the [branching and creation of a new development streams](#branching-and-creation-of-a-new-development-stream). +### Post Development Work +When development is nearing its end, set a release date in task 5 and start planing task 1. +Once the development work is complete follow the epic release steps for the administrative, security, and documentation tasks. + +To release follow: +* [Release the operator (for OCP)](#release-process-for-ocp) +* [Publish a bundle in the OCP's OperatorHub's FBCs](#publish-a-bundle-in-the-ocps-operatorhubs-fbcs) + +Note: These steps are happening simultaneously. + +The general steps are: +* Cherry-pick changes for the release onto release branch +* Get an operator snapshot + * validate all the pipeline runs and document the digests +* Run the FBC staging release +* Follow up with docs +* Have QE and ProdSpec validate the fbc release +* Run the operator release +* Update the tags in git and internal release frameworks + * Check the epic tasks for other steps +* Run all the FBC releases on the release date + + For examples: + * [v1.1.1](https://redhat-internal.slack.com/archives/C06ECDGH4LE/p1761070678851309) + * [v1.2.0](https://redhat-internal.slack.com/archives/C06ECDGH4LE/p1760127394479789) \ No newline at end of file