Support reading and comparing OSVersion on Linux platform.

[make1980]

The OCI image spec contains the OSVersion field as part of the platform spec. However, this field isn't used on Linux platform. We have a scenario where container version will need to be dependent on the OS version because container images and OS images are built and qualified from the same release branch, which requires this feature.

The current implementation of containerd doesn't support this functionality because the platform module doesn't have functionality to read or compare OSVersion on Linux.

One solution is to add this support in the platform module so that OSVersion can be read from a configuration file such as /etc/os-release on Linux, using the VERSION_ID as the key to look up the version.

To support various Linux distributions we can allow the OS version config file path and config key to be customized through environment variables.

For example, the following environment variables can be defined:

export USE_OCI_OS_VERSION=true
export OCI_OS_VERSION_CONFIG_FILE=/etc/foo.yml
export OCI_OS_VERSION_CONFIG_KEY=bar

and in /etc/foo.yml file the following content can allow the OS version to be read as 1.0:

bar=1.0

An alternative to this solution is to update the CRI interface so that platform can be passed in(today there is only annotations field that can be potentially used but none of the platform fields is using it).

The alternative requires changes to containerd and all the CRI client implementation(kubelet/dockerd etc) so will be much more work. Also it's inconsistent with how containerd gets the OS and architecture values - containerd gets those values based on the golang runtime(so by itself).

[make1980]

Note that I have a change ready for this issue - please let me know if it helps with understanding the proposal so that I can publish it.

[estesp]

I know you are potentially focused on a narrower set of "comparators" than this OCI working group, but I think containerd (if I may attempt to speak for the project; and to be clear, others may have different views) would want to follow anything that comes from an official OCI movement towards more platform matching that has been a long-time topic, and finally has a WG within the OCI to propose solutions. You can check out the WG here at their repo: https://github.com/opencontainers/wg-image-compatibility

Recent meeting notes and many other links here: https://hackmd.io/060HKC3DTV-NzzewNQbHCg?view

[make1980]

Thanks a lot for the pointers! Great to see the effort for broadening the image compatibility support with all the heterogeneous HW/SW environments that are developing rapidly.

Our current requirement is still relatively simple though, which is already supported by the existing interface of OCI. In the long run we might have some similar compatibility requirements(like different HW SKU might need different version of image) but an alternative solution could also be having one image which can fork its behavior based on node capability at run time, instead of having different images for nodes with different capabilities. I understand that there will be limitations for this approach and it can increase the complexity of the container logic.

So how should we proceed with this present issue in our scenario? I think this can be well supported by any of the proposals and most will be an overkill for our case (especially proposal D :) so not sure if our case will be able to bring too much value for the discussion.

[samuelkarp]

This seems like a bit of an XY problem request right now. What is the underlying problem you're attempting to solve?

We have a scenario where container version will need to be dependent on the OS version because container images and OS images are built and qualified from the same release branch, which requires this feature.

Do you have more details about the use-case you're attempting to satisfy?

[make1980]

Yes. The use case is like this - we have large amount of devices(tens of thousands of at least) that are running Debian Linux with different versions. These devices are added to a k8s cluster to manage the container rollout on them. The containers are built together with the Debian Linux by ourselves through individual release branches. For example 20.11 Debian can have a release branch 20.11 which contains all the code/modules for Debian 20.11 and the container services. The OS image and container images are generated from this release branch and both are labeled as 20.11. The OS and container are both qualified together as version 20.11.

In the meantime we're maintaining multiple release branches such as 21.11, 22.11 etc. These branches contain different versions of Debian OS and different implementations of the container service because of the dependency from the container service to some baked in binaries in the OS image.

In the datacenter we have these devices with all different OS versions because the OS version upgrade is a lengthy process. Now when we use k8s to deploy these containers as a DaemonSet, we don't want to create one DaemonSet for each OS image version because of the maintenance cost. Instead we have one DaemonSet and we rollout the container images to all the devices. On each device, we expect kubelet + containerd to get the corresponding container image version based on the OS image version. However there isn't this kind of capability based on my understanding in kubelet/containerd. Containerd seems to have a client which can support it but given kubelet uses CRI interface which doesn't have platform information in its contract it cannot be used as is.

Hope this clarifies - let me know if you have any questions.

[make1980]

Any suggestions on how this scenario can be supported? @samuelkarp