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

Brian Gollaher briang at redhat.com
Wed Oct 21 20:22:41 UTC 2015


On 10/21/2015 08:23 AM, Jim Perrin wrote:
>
> On 10/21/2015 01:14 AM, Honza Horak wrote:
>> On 10/20/2015 11:29 PM, Honza Horak wrote:
>>> 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
>>> https://github.com/projectatomic/ContainerApplicationGenericLabels/blob/master/vendor/redhat/names.md.
>>>
>>>
>>> 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.
>> Thinking about a typical example where platform matters -- let's say a
>> developer wants to speed-up a ruby application, so he implements a part
>> of it as a binary extension (written in C and using a library from the
>> base OS).
>>
>> The developer builds the app locally, so the rubygem links to the
>> particular system library (libfoo.so.2). Once our images would move from
>> rhel7 to rhel8, his application wouldn't work any more, because we have
>> libfoo.so.3 in rhel8.
>
> This level of breakage happens outside containers even in the minor
> point release updates. This was shown quite recently with the
> ImageMagick update in 6.7 [1]. To me this isn't a good enough
> justification (on the community side) to duplicate names. None of the
> fedora containers specify OS version, nor to the CentOS containers.
>
>
> For RHEL support and RH's own container registry it's fine and the
> occasional edge case makes sense there. From the community perspective,
> we should align with where the entire ecosystem as a whole is going.
>
> Right now we're lagging in usage, and doing things very differently from
> what the ecosystem expects is only going to further isolate us.
>
>
> In the world of containers, the application is the visible component,
> not the OS. It's a shift away from what we've been doing for the last
> decade, but it's happening.
Yes but our business is selling a secure, stable OS with long term 
support so keeping the -rhel7 helps customers understand where they can 
confidently use the container.
>
>
>
> 1.
> https://lists.fedoraproject.org/pipermail/epel-devel/2015-July/011419.html
>

-- 
Brian Gollaher
Red Hat Platform Product Management
Phone: 978 392-3173
Cell: 508 740-6549
briang at redhat.com




More information about the SCLorg mailing list