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

Honza Horak hhorak at redhat.com
Thu Oct 8 09:43:53 UTC 2015

On 10/07/2015 11:40 AM, Karanbir Singh wrote:
>>> 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 )

Fair point. Anyway, what a sane user actually does IMO is not `docker 
pull mariadb`, but rather `docker pull mariadb:5.5`. And  since `docker 
search centos/mariadb` doesn't show available versions, how can user 
know which versions are available? there is only centos/mariadb in the 

So, user can only guess what versions are available or can find it 
somewhere else.. in the case there would be the version in the image 
name, it would be listed in the search output, which seems like a 
benefit for user to me.

Btw. did you know that there has been already centos/mariadb available 
on docker hub?

> * provides scope for future expansion as we abstract away from
> delivery mechanics to focus on payload

I still don't consider this to be related to delivery mechanism.

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

Sure, nobody runs 'yum install mariadb-5.5.44-1.el7_1.x86_64' and just 
uses `mariadb`, but we must realize that users always install RPMs for 
the correct platform (nobody configures yum to install el6 packages on 
el7) and we also provide only one version of the mariadb in the system, 
so users are sure what version they get. Once there are more versions 
(as SCLs or if we find any other format), users will install particular 
version -- `yum install mariadb55`, because they care (in most cases).

Docker is new in this sense because you have all versions build on 
various kernels on one heap. This is not something we have experience 
with in RPM world.

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

The SCL part is there already, but covers only RH registry. I wish we 
could sync on one schema over Fedora/RHEL/CentOS as well, but I don't 
see a compromise here, that would be fine for all. Or maybe missing 
willingness to accept some compromise, I don't know.

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

IMO the chance would be big enough if we'll be convinced the current way 
is not good enough for users. If we'll see the current way is fine for 
them and doesn't make any troubles, then why changing it..


More information about the SCLorg mailing list