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

Karanbir Singh kbsingh at redhat.com
Tue Oct 20 12:15:32 UTC 2015


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

Hi folks, just a quick ping back - does anyone have thoughts around
this ?

We are getting ready to start pushing SCL's from centos.org and that
will likely map back to the docker containers and getting the pipeline
for those into ci.centos.org.

The 19th Nov isnt far either,

Regards,

On 09/10/15 20:41, 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 at redhat.com 
> <mailto:hhorak at 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 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 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' 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..
> 
> Honza
> 
> 
> 
> 
> -- Ben Parees | OpenShift
> 


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

iQEcBAEBAgAGBQJWJjBjAAoJEI3Oi2Mx7xbtC0cIAJTxE4rFvXZxuRRgCnbnfEA4
mN9lb7fAhYNvsCSk6SO+V2HZmS/zDFJ64Vqb6mm2w9U3kt/5JQ0fjSXY3GM/jGgB
H00T/vxlt7fIMqZ1TTV6bTut/hSa7dYd/kko+VTGKQaPe6UtBmZH8X2iGWgw/E10
AYu0IHOW7Dd9pfE1MYHnVHdPsru+//raCO5bdjH+gEYhL7d9mhtp5RMOkyQ+y2BN
c7yvtujyh7LzPuqmXJrnxYtZVQu0RI99J5el5zCBzfE9rBtY2qoYGS4KJnC9y02C
Nhtt+Ixt+W41GsbgwGKZqLsAG1ogcUoMQghiyyPVEv00X+d3xPp0659Knsbz08Y=
=31Dn
-----END PGP SIGNATURE-----




More information about the SCLorg mailing list