#6 kubernetes image versioning discussion
Opened 6 years ago by jasonbrooks. Modified 6 years ago

Upstream kubernetes containers follow the naming/versioning convention of name-arch:version, for instance : gcr.io/google_containers/hyperkube-amd64:v1.6.7.

Fedora's containers can be accessed by name:version: registry.fedoraproject.org/f25/kubernetes-apiserver:0.1, but the versions don't correspond to the rpm version, because we don't have an automated way to do that (see Fedora Container Guidelines on Versioning).

It would be good to have a more upstream-ish container naming scheme for kubernetes, to make it more familiar to users familiar with the upstream convention, and to make potential efforts like swapping out the debian-based upstream kube images for fedora ones in kubeadm easier to accomplish.

Automatically updating the image version to match the rpm is on the build system roadmap, but we could manually sync the version number in the mean time.

I believe that Fedora's build system only builds amd64 packages at this point, but I wonder whether we should think/talk about putting arch in the name in the way that kube does upstream to prepare for a multi-arch future.


Until the version label is populated manually, can we start tagging manually with:
$VERSION-$RELEASE or only $VERSION.

i.e. v1.7.3-1 (rawhide or f26 or fX is included in the group?) otherwise v1.7.3-1.rawhide

The version option would be the same as the upstream kube_version v1.7.3

Login to comment on this ticket.

Metadata