[Release] Check list for v0.9.0

[fitzthum]

v0.9.0

Overview

The release process mainly follows from this dependency graph.

flowchart LR
    Trustee --> Versions.yaml
    Guest-Components --> Versions.yaml
    Kata --> kustomization.yaml
    Guest-Components .-> Client-tool
    Guest-Components --> enclave-agent
    enclave-cc --> kustomization.yaml
    Guest-Components --> versions.yaml
    Trustee --> versions.yaml
    Kata --> versions.yaml

    subgraph Kata
        Versions.yaml
    end
    subgraph Guest-Components
    end
    subgraph Trustee
        Client-tool
    end
    subgraph enclave-cc
        enclave-agent
    end
    subgraph Operator
        kustomization.yaml
        reqs-deploy
    end
    subgraph cloud-api-adaptor
        versions.yaml
    end

Starting with v0.9.0 the release process no longer involves centralized dependency management. In other words, when doing a CoCo release, we don't push the most recent versions of the subprojects into Kata and enclave-cc. Instead, dependencies should be updated during the normal process of development. Releases of most subprojects are now decoupled from releases of the CoCo project.

The Steps

Note: It may be useful when doing these steps to refer to a previous example. The v0.9.0-alpha1 release applied these changes. After following steps 1-5 below, you should end up with a similar set of changes.

Determine release builds

Identify/create the bundles that we will release for Kata and enclave-cc.

• [x] 1. :eyes: Create enclave-cc release

  Enclave-cc does not have regular releases apart from CoCo, so we need to make one. Make sure that the CI is green and then use the Github release tool to create a tag and release. This should create a bundle here.

• [x] 2. :eyes: Find Kata release version

  The release will be based on an existing Kata containers bundle. You should use a release of Kata containers. Release bundles can be found here. There is also a bundle built for each commit. If you absolutely cannot use a Kata release, you can consider releasing one of these bundles.

• [x] 3. :eyes: Create a peer pods release

  Create a peer pods release based on the Kata release, by following the documented flow.

Test Release with Operator

• [x] 4. :eyes: Check operator pre-installation and open PR if needed

  The operator uses a pre-install container to setup the node. Check that the container matches the dependencies used in Kata and that the operator pulls the most recent version of the container.

  • Check that the version of the nydus-snapshotter used by Kata matches the one used by the operator
    • Compare the nydus-snapshotter version in Kata versions.yaml (search for nydus-snapshotter and check its version field) with the Makefile (check the NYDUS_SNAPSHOTTER_VERSION value) for the operator pre-install container.
      • If they do not match, stop and open a PR now. In the PR, update the operator's Makefile to match the version used in kata. After the PR is merged, continue.

• [x] 5. :wrench: Open a PR to the operator to update the release artifacts

  Update the operator to use the payloads identified in steps 1, 2, 3, and 4.

  Make sure that the operator pulls the most recent version of the pre-install container

  • Find the last commit in the pre-install directory
    • As a sanity check, the sha hash of the last commit in that pre-install directory will correspond to a pre-install image in quay, i.e. a reqs-payload image here.
  • Make sure that the commit matches the preInstall / postUninstall image specified for enclave-cc CRD and ccruntime CRD
    • If these do not match (for instance if you changed the snapshotter in step 4), update the operator so that they do match.

  There are a number of places where the payloads are referenced. Make sure to update all of the following to the tag matching the latest commit hash from steps 1, 2, and 3:

  • Enclave CC:
    • sim
    • hw
    • base
  • Kata Containers:
    • default
    • s390x
    • peer-pods Note that we need the quay.io/confidential-containers/runtime-payload-ci registry and kata-containers-latest tag

  Also, update the operator version (update the newTag value)

Final Touches

• [x] 6. :trophy: Cut an operator release using the GitHub release tool

• [x] 7. :green_book: Make sure to update the release notes and tag/release the confidential-containers repo using the GitHub release tool.

• [x] 8. :hammer: Poke Wainer Moschetta (@wainersm) to update the release to the OperatorHub. Find the documented flow here.

Post-release

• [ ] 9. :wrench: Open a PR to the operator to go back to latest payloads after release After the release, the operator's payloads need to go back to what they were (e.g. using "latest" instead of a specific commit sha). As an example, the v0.9.0-alpha1 release applied these changes. You should use git revert -s for this.

[fitzthum]

There have been no changes to enclave-cc since our last release, so let's just stick with v0.9.1

[wainersm]

Kata 3.7.0 is out: https://github.com/kata-containers/kata-containers/releases/tag/3.7.0

[wainersm]

As per discussion on https://cloud-native.slack.com/archives/C04A2EJ70BX/p1721840996578619 , step 3 (Create a peer pods release) will be done after operator's release.

[fitzthum]

Time to poke @wainersm

[wainersm]

Checking steps 3 and 8 as peer pods is released (https://github.com/confidential-containers/cloud-api-adaptor/releases/tag/v0.9.0) and the operator published in hub (https://operatorhub.io/operator/cc-operator).

@fitzthum time to work on 9

[portersrc]

Is it OK to close this? Was step 9 correctly completed with this?

[fitzthum]

Is it OK to close this? Was step 9 correctly completed with https://github.com/confidential-containers/operator/pull/401?

I think the last step was completed given that there is. v0.9.0 release here