[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: [scl.org] Image naming for centos-based images
- From: Honza Horak <hhorak redhat com>
- To: Ben Parees <bparees redhat com>, Brian Gollaher <briang redhat com>
- Cc: "sclorg redhat com" <sclorg redhat com>, Karanbir Singh <kbsingh redhat com>, Scott Collier <scollier redhat com>, Fedora Environment and Stacks Working Group mailing list <env-and-stacks lists fedoraproject org>, Daniel McPherson <dmcphers redhat com>, Vaclav Pavlin <vpavlin redhat com>, Daniel Riek <riek redhat com>, Michal Fojtik <mfojtik redhat com>, Clayton Coleman <ccoleman redhat com>
- Subject: Re: [scl.org] Image naming for centos-based images
- Date: Tue, 20 Oct 2015 23:29:53 +0200
I'm wondering whether the silence means nobody has any objections or
whether everything was already said..
Anyway, there is still the risk of using names without rhel7 and centos7
suffix like `centos/mariadb-100` or `rhscl/mariadb-100`, that user won't
be sure what is the OS version in the container -- that is considered
relevant in more parts of
That ^ is also the view I'm more leaned towards, simply because I agree
with the points in the document above and because I don't think platform
version makes any harm in the name. On the other hand, the Docker world
works without platform version or even component version in the name, so
it shouldn't be that bad in the end.
So, technically we're able to change the names for RHSCL images now
after they are available as Beta, but I'm not sure whether it is still
possible from PM PoV -- Brian, would it be possible to change names of
the images from e.g. `rhscl/mariadb-100-rhel7` to `rhscl/mariadb-100` at
On 10/09/2015 09:41 PM, Ben Parees wrote:
Karanbir and I talked briefly today, and i'd like to just lay out a
couple things from an openshift perspective:
1) we encourage the use of both rhel and centos images (rhel for
support, centos to try), so we really want the images to have the same
names (other than the namespace/org) because it makes for a much more
consistent transition, better support experience, etc. So i do not like
any approach that results in one naming convention for centos images and
another for the "rhscl" images.
2) we're shipping OSE3.1 nov 19th and things need to be locked down
earlier than that. Since this will be the first release shipping these
new SCL images, we have some freedom to change the names now. But once
that happens it's going to be much more painful to change them. So if
things are changing, we need a decision asap.
3) I suggested that maybe we could use aliases to solve some of this...
you can still provide a "mariadb" docker alias for the seamless "i don't
care what i get" experience, but still maintain multiple streams of
versions/etc by backing that alias with a more specifically named pull
spec, like the names we use today.
4) i'm mostly willing to concede dropping the rhel7/centos7 suffice from
the names now that we have separate namespaces for the
repositories...but keeping the version number in the name still seems
important to avoid the issues with users not being able to pull "latest"
or not understand what they have pulled.
I'm also adding Dan McPherson and Clayton Coleman to this thread as they
are the lead architects for OpenShift and should also weigh in on any
image naming decisions we're making.
On Thu, Oct 8, 2015 at 11:43 AM, Honza Horak <hhorak redhat com
<mailto:hhorak redhat com>> wrote:
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
hub uses for official images now
adding a few more bits here for B :
* pretty much the standard way for the entire docker ecosystem
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 output.
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'
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 , there is a new API spec being
prepared , which will be a chance to change naming scheme to
something less redundant, if the current way proofs to be
 isnt complete so its clearly a work in progress, how about
work on getting that complete now and address the whole piece
? 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
largely driven by we-already-have-something, what are the
this is going to go away when the api-spec comes up ( and we
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..
Ben Parees | OpenShift
[Date Prev][Date Next] [Thread Prev][Thread Next]