Image naming for centos-based images

Tue Oct 6 08:20:38 UTC 2015

On Friday 02 of October 2015 12:16:55 Honza Horak wrote:
> This is a follow-up for the meeting we had yesterday and which there are
> minutes from at:
> https://lists.fedoraproject.org/pipermail/env-and-stacks/2015-October/000946.html
>
> One thing that we couldn't solve without any OpenShift representative
> was naming scheme for the centos images, that are based on SCL packages.
> Those were originally called (mysql chosen as example):
>    openshift/mysql-55-rhel7
>    openshift/mysql-55-centos7
>
> the new versions are located under rhscl (RH internal registry) and
> centos (docker hub) namespaces (variant A):
>    rhscl/mariadb-100-rhel7
>    centos/mariadb-100-centos7
>
> What we were thinking about yesterday was this scheme (variant B):
>    rhscl/mariadb-100-rhel7
>    centos/mariadb:10.0

+1 for DISTRO/MAJORCOMPONENT:TAG for now.

> Reasoning for shorter/simpler naming (variant B):
> * we want to hide the fact that image is using SCL, so there is no need
> to distinguish between SCL and non-SCL images

I'm not sure about this.  Yes, I don't care about "technology" used
underneath (SCL), but from the user POV, I would expect
'DISTRO/COMPONENT:MAJORVERSION' image *will* be supported as long as the
DISTRO/COMPONENT package.  Having there
'centos/mysql-scl:MAJORVER-DISTVER' would much clearer say that the image
will be supported for shorter period.

If we shipped non-SCL package, as a corporate database-container user -> I
would personally prefer a non-SCL package over SCL one because I would
have guarantees that the image will work probably 10+ years without any
data migration or API breakage (thats what the CentOS policy is about,
or?).  Thats why I would like to have 'centos/mysql:..' reserved for
non-SCL image.

The reason why we plan to ship only SCL images for now is that those
images are more or less designed for/needed by OpenShift -- and that
environment prefers features over long-time support (SCL over non-SCL).

> * there doesn't seem to be a reason to have more variants of one
> component in the image (if there will be in the future, the name itself
> should be different)
> * image name should be simple for users
> * it is a benefit to use the same scheme as on docker hub
> * distribution version underneath is usually irrelevant (except some
> specific cases, like some base libraries; anyway it won't be good enough
> reason to provide two variants of images just for the sake of different
> libraries underneath), so the -centos7 suffix is not necessary

Similarly, we'll support CentOS 7 much longer than CentOS 6 from now.  If
we were able transparently migrate e.g. from 'centos/mysql:X.Y-el6' to
'centos/mysql:X.Y-el7', it wouldn't be a problem and we could omit the
distro flag.

As long as this long-time support is important for CentOS users in general
(and their decision why to choose CentOS image), it is to some extent
important to have the info about distro in the "image name" (== repository
+ tag).

> However, after talking to Ben from OpenShift there are actually some
> arguments for using distro version and also version in the name (variant A):
> * Ben claimed the distribution underneath is actually important, because
> of kernel. Once there is centos8-based image, it might or might not run
> on centos7 machine. Whether this happens in reality or not, we should at
> least have a backdoor how to fix it.
> * version in the image name instead of just tag is handy for the cases
> where we want to work with :latest tag (used quite a lot in docker
> world, default behaviour)
> * no version in the image name also means that if users don't use tags,
> they will upgrade to newer version once new version is out (which e.g.
> in case of mysql 5.6 to 5.7 upgrade can cause troubles).

This is _very_ important argument, could we suggest to not use :latest,
but rather explicit tag?

> * since RH internal naming is not expected to be changed, the new
> suggested variant will be more confusing for users, since they won't
> understand that rhscl/mysql-56-rhel7 is the same image as centos/mysql:5.6.
> * Ben also mentioned users haven't had problems with image naming so far
>
> Since there is no ideal solution, we may consider also some compromise,
> like:
>    centos/mysql-56
>
> ..and have tags for the distribution (centos7) same as centos base image
> has, which would be a solution for the case distribution would matter
> once in the future.

This compromise sounds better to me..:  The '-56' suffix could play the
role of '-scl' I mentioned above (and clearly say that the mysql component
in this image is somehow specific, SCL/OpenShift/.../supported shortly).

Docker v2 API [1] seems to implement mutiple "path components" -- so we
could later migrate to different schema like "centos/6/mysql:latest"..
But taking this into account, the TAG should be IMHO considered as
_important_ part of "image name" anyway (while "image name" should at
least clearly say non-(SCL), distro version and component-major-version).

[1] http://docs.docker.com/registry/spec/api/

Thanks, Pavel

> The general rule for the image name in the centos would be:
>    use <pkgname> for cases where version of the image doesn't care
>    use <pkgname>-<majorversion> for cases where version of the image
> matters, where it is expected that users will require a specific version
> of the image and upgrading to a newer version must be always under their
> control.
>
> What do you think?
>
> Honza
> _______________________________________________
> env-and-stacks mailing list
> env-and-stacks at lists.fedoraproject.org
> https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks