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

Karanbir Singh kbsingh at redhat.com
Wed Oct 7 09:40:37 UTC 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/10/15 10:04, Honza Horak wrote:
> 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

adding a few more bits here for B :

* pretty much the standard way for the entire docker ecosystem to work
on right now ( that redhat is largely absent from )
* provides scope for future expansion as we abstract away from
delivery mechanics to focus on payload
* allows for distro decompose and co-exist in a 'as default' manner (
admittedly arguable! )

A relatively sane proof for this model is looking at how many people
run a 'yum install mariadb' V/s 'yum install
mariadb-5.5.44-1.el7_1.x86_64' when they want a mariadb install;
having a centos/mariadb and using tag space to extend the multiple
version availability, allows us to extend the same user expectation.

> 
> 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.

[1] isnt complete so its clearly a work in progress, how about we just
work on getting that complete now and address the whole piece together
? or is the SCL portion left as TBA allowing the scl space to do
something completely different ?

Secondly, if you consider the inertia against looking at a change now
largely driven by we-already-have-something, what are the chances that
this is going to go away when the api-spec comes up ( and we have even
more water under the bridge ? ).

> 
> 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/blo
b/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


regards,

- -- 
Karanbir Singh, The CentOS Project, London, UK
RH Ext. 8274455 | DID: 0044 207 009 4455
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJWFOiVAAoJEI3Oi2Mx7xbtXHkH/R5V/OgH0BB4u0BT7b8ub3YT
sd1AfgXRSXGVDilTTs55l6HfZjFKvkN3r+tvIA6yLS/04IvoZeZkHaFS7txP1sN9
cNJU3a26yEbKJUbsFVkesIfl4mWeds9S/JTIJ9srd6QSRBGW5WfYGtXeV4pdcmDU
ifUVbrxLKYuxlG8gKjve6JUPu07JLCkr74a/T7jmSS6ptp5eVH9Yfs5tJKmu0Tiv
bBG0c92Pwo3wIpJVNDaBd2DzDKjaxxbUv6wvWKlxi5yuVxmFUcEPOblXqFmfBYja
4FUYp/w5tgJ/GYb4514f83bNYQv+cWvmi8CXR6XSqY+o+9p/oCut/qn54SjgL5o=
=5694
-----END PGP SIGNATURE-----




More information about the SCLorg mailing list