[scl.org] Image naming for centos-based images

Honza Horak hhorak at redhat.com
Wed Oct 7 09:04:52 UTC 2015


Thank you all for the input. I'm trying to summarize the pros of both 
variants in-line, because we need to move forward..

On 10/02/2015 12:16 PM, Honza Horak wrote:
> variant A:
>    centos/mariadb-100-centos7

* consistent with what is already standardized in RH [1]
* prevents potential issues when platform underneath matters (not clear 
now whether it is a real issue or not)
* is explicit about the version (which is usually important for users, 
might be important for "support period" specification)
* has already been used for now
* proofed to be working for OpenShift (users seem to be fine with it)

> variant B:
>    centos/mariadb:10.0

* less complicated
* no redundancy
* it is similar to what docker hub uses for official images now

Well, there is no clear answer here. Since we need to focus on what 
problems it causes to users, from my PoV, the Variant A brings a bit 
more, even if it is more complicated and includes redundancy (but it is 
one-time effort for user to understand the naming and hopefully it is 
still self-explanatory).

Considering also that some images like centos/mariadb-100-centos7 are 
already available on docker hub, I'm proposing to stay with this variant 
(A) now.

As mentioned in this thread [2], there is a new API spec being prepared 
[3], which will be a chance to change naming scheme to something less 
redundant, if the current way proofs to be problematic.

I'd like also to propose creating centos variant of naming guidelines 
[1], which should prevent similar discussion in the future. I see centos 
being mentioned in the RH guidelines as well, most probably for being 
consistent, so adding Daniel to CC (who originally wrote the guidelines).

[1] 
https://github.com/projectatomic/ContainerApplicationGenericLabels/blob/master/vendor/redhat/names.md
[2] https://www.redhat.com/archives/sclorg/2015-October/msg00010.html
[3] http://docs.docker.com/registry/spec/api/

Honza




More information about the SCLorg mailing list