Handling of non-golang dependency versions

[jodh-intel]

In Clear Containers, we have come to rely quite heavily on a file we maintain called versions.txt:

• https://github.com/clearcontainers/runtime/blob/master/versions.txt

That file is used to define the versions of various depenencies for Clear Containers. For example:

• supported version of golang.
• hypervisor version details.
• docker version.
• k8s version.
• rootfs image version from Clear Linux.

This file avoids hard-coding versions details in lots of different files (which makes maintenance very difficult). It is a simple database file in name=value format (crucially with comments) that can be sourced as a shell script or grep'd.

It's important to state that this file is not only used by the Clear Containers runtime repository: it is also used by the tests and packaging repositories to query version details.

We are going to need an equivalent for Kata Containers, but I'm wondering if we want to consider refining the approach slightly. The current approach is simple and proven, but it doesn't have much structure. A way of grouping variables would be very useful, for example for the CentOS package versions here:

• https://github.com/clearcontainers/runtime/blob/master/versions.txt#L42..L49

Hence, I think we should consider creating a versions.yaml for Kata. We could then use a tool like https://github.com/mikefarah/yq to query the file:

$ go get github.com/mikefarah/yq
$ yq read versions.yaml centos.deps.glib.version
2.46.2
$ yq read versions.yaml docker.swarm.version
1.12.1

The advantage of YAML over JSON being a lot more flexibility in terms of structure, and -- a "killer" feature -- it supports comments! 😄

What do you think @sameo, @grahamwhaley, @chavafg, @gnawux, @bergwolf ?

[jodh-intel]

ping @kata-containers/runtime - are we happy with the YAML approach?

[sboeuf]

Fine with me !