workflow: pin docker image version to release version

[ChengyuZhu6]

pin docker image version to release version.

[wainersm]

Hi @ChengyuZhu6 !

Thanks for working on this; on Kata CI we use these deployments to install nydus-snapshotter and we realized while ago that the version wasn't pinned, thus this is very important to us.

One problem that I see with this fix is that the misc/snapshotter/base/nydus-snapshotter.yaml gets changed after the repository tagging. The way that Kata CI consume these files is by cloning the repo and checking the release tag, and in this case misc/snapshotter/base/nydus-snapshotter.yaml will be still pointing to latest image. This a chicken-or-eggs situation that I've seen in peer pods and other projects :(

One way of solve that problem is to consume this project tarball sources file. There the misc/snapshotter/base/nydus-snapshotter.yaml will be pointing to the right and pinned image. On the other hand, by leveraging this approach we lose the ability to consume this project from a given commit SHA-1.

There is another approach that I will say later because I will be better expressing the idea in code :)

[wainersm]

The other idea I mentioned above is to create a new release overlay that overwrites the image tag on the base deployment. Something like that:

$ tree
.
├── base
│   ├── kustomization.yaml
│   └── nydus-snapshotter.yaml
├── config-blockdev.toml
├── config-proxy.toml
├── config.toml
├── Dockerfile
├── nydusd-config.fscache.json
├── nydusd-config.fusedev.json
├── nydusd-config-localfs.json
├── nydus-snapshotter.fscache.service
├── nydus-snapshotter.fusedev.service
├── nydus-snapshotter-rbac.yaml
├── nydus-snapshotter.service
├── overlays
│   ├── k3s
│   │   ├── kustomization.yaml
│   │   └── mount_k3s_conf.yaml
│   ├── release
│   │   └── kustomization.yaml
│   └── rke2
│       ├── kustomization.yaml
│       └── mount_rke2_conf.yaml
└── snapshotter.sh

6 directories, 19 files

$ cat overlays/release/kustomization.yaml 
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base

# newTag points to the latest release image and must be updated before tagging a new release
images:
- name: ghcr.io/containerd/nydus-snapshotter
  newTag: v0.13.9
$ kustomize build base/ | grep ghcr.io/containerd/nydus-snapshotter
        image: ghcr.io/containerd/nydus-snapshotter:latest
$ kustomize build overlays/release/ | grep ghcr.io/containerd/nydus-snapshotter
        image: ghcr.io/containerd/nydus-snapshotter:v0.13.9

The overlays/release/kustomization.yaml file should be updated to the release tag before tagging the repo and creating the release. Users will install the release snapshotter with kubectl apply -k overlays/release then.

This isn't a novel idea nor mine. It's being used on the CoCo operator too, see https://github.com/confidential-containers/operator/tree/main/config/release and https://github.com/confidential-containers/operator/blob/main/docs/INSTALL.md#deploy-the-operator

[ChengyuZhu6]

Hey, Wainer @wainersm I have made the changes as your suggestion. Would you mind re-reviewing it ?

[imeoer]

Hardcoding the release version into the yaml before release is easy to overlook. Can we modify the version in the yaml on releasing? so that users only need to wget the tar.gz, extract the tar.gz, and then use kubectl apply yaml?

[wainersm]

Hi @imeoer !

Hardcoding the release version into the yaml before release is easy to overlook. Can we modify the version in the yaml on releasing? so that users only need to wget the tar.gz, extract the tar.gz, and then use kubectl apply yaml?

Yes, it is a solution. In Kata we would need to change the algorithm to pull the tarball rather than clone the repo, and this isn't so difficult. Other consumers of this problem will need to be know that the tarball is the way forward to install it (at least using the daemonsets...etc)