[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



On 10/21/2015 05:00 PM, Karanbir Singh wrote:
On 21/10/15 21:59, Jim Perrin wrote:

On 10/21/2015 03:22 PM, Brian Gollaher wrote:
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.

No, we're talking about something larger here. Fedora and CentOS don't
sell anything. This is where community and RH business interests
diverge. If RH wants to add to the naming schema within their own
registry, that's entirely fine and understandable. I don't see a need to
drive a business mandate into the community space, especially when the
larger container community is moving in the opposite direction.
also, isnt rhel7 content already delivered via a layered  private
repository anyway ?
Yes it is.

I sincerely hope were not asking customers to rely on a bit in the name
to build trust ( anyone can push an image called -rhel7 ).
My assumption was that container names would be consistent. Where we have images built on rhel7 base that run on rhel7 and rhel8 hosts (or centos7 and centos8 hosts), how do identify that the image is built with rhel7 base?


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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]