[RFE] publish containerd versions via flatcar_production_image_packages.txt

[dongsupark]

Current situation

At the moment, there is no way to fetch a containerd version of a specific Flatcar version or channel. That is different from other packages like docker, which are easily available on both flatcar_production_image_packages.txt and the Flatcar releases website. It has been always like that since the beginning of torcx. It is one of the most confusing aspects of Flatcar.

Edit: Initial context was:

Recently that issue came up during a discussion in Cluster API image-builder, about how to specify containerd version for a specific Flatcar version. In the past the containerd version and its sha256 checksum were simply specified in Flatcar-specific config. However, the Flatcar-specific config was in the end removed by the PR, as wanted by image-builder maintainers. As a result, from now on, if the master branch of image-builder has a different containerd version from Flatcar, we need to specify environment variables before running hack/image-builder-flatcar.sh, like:

FLATCAR_CONTAINERD_VERSION=1.5.4 \
FLATCAR_CONTAINERD_SHA256=591e4e087ea2f5007e6c64deb382df58d419b7b6922eab45a1923d843d57615f \
./hack/build-image-flatcar.sh stable

Ideally the Flatcar containerd version and sha256 should be automatically generated according to the actual Flatcar channel.

What we need for that:

• containerd version should be published via flatcar_production_image_packages.txt for each Flatcar version.
  • It might be doable by publishing a package manifest for the docker.torcx package .
• (optional) the containerd version could be also published on the Flatcar release page.

Additional information

Related discussion: kubernetes-sigs/image-builder#670

[jepio]

So there is something i don't understand. Here's how I understand things:

• image-builder does not install containerd on flatcar
• the containerd version passed while building flatcar AMIs is only used to check the version contained within the OS

So what's the point of passing a containerd version at all? It would make sense to remove the containerd version related checks on Flatcar and rely on what's in the OS image.

What am I missing?

[pothos]

We talked about it today and suggest two things:

• disable auto-updates (mask update-engine) so that the containerd version doesn't change and the built Flatcar image by default behaves more like other images
• when a particular containerd version is required, it should get downloaded to /opt and overwrite the Flatcar in-built version similar to https://kinvolk.io/docs/flatcar-container-linux/latest/container-runtimes/use-a-custom-docker-or-containerd-version/ (but possibly through setting up a bind mount because the PATH is hard to configure systemd-wide)

[jepio]

Found out it's slightly more involved: containerd is taken from the image but containerd-shim-runc is taken from an upstream tarball, that's why the version has to match. But Flatcar ships the container-shim-runc binaries already so it doesn't make sense.

Doing what @pothos wrote in the second bullet point will clear this up.

[pothos]

I don't have the clarity yet if there is a strong coupling of containerd and the rest that's put on the image or if Flatcar's inbuilt version is enough.

[pothos]

We filed a PR which implements the setup of the requested version in /opt.

Including the contained version in flatcar_production_image_packages.txt is still wanted and there are two options: remove torcx and install containerd directly to the image, or query the torcx package versions and append them to the package file.

[jepio]

Solved via flatcar/scripts#217. I'll close this as it trickles into stable channels.