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

Nick Coghlan ncoghlan at redhat.com
Thu Oct 22 16:08:30 UTC 2015


On Thu, Oct 22, 2015 at 1:19 PM, Petr Pisar <ppisar at redhat.com> wrote:

> On Thu, Oct 22, 2015 at 01:03:27PM +0200, Honza Horak wrote:
> > I expect we want the centos-based images be run everywhere, not only
> centos,
> > but on Fedora, Debian or even Windows if possible.
> >
> Impossible. Docker image is archived file system without kernel. The
> archived
> executables depend on kernel ABI.
>

Folks running highly optimised C/C++/FORTRAN  applications may care about
the exact kernel version, but that's not your typical containerised
application.

When language runtimes are written to be portable across Windows, Linux and
Mac OS X, the differences between Linux kernel versions generally vanish
into the noise, so if a Java/Python/Ruby/Node.js container crashes because
you ran it on a different kernel, that's an extreme edge case.

Even when there *are* ABI compatibility issues, if an app is designed to be
failure tolerant, bugs in the *app itself* are still far more likely to be
the culprit for a server 500 error than a kernel ABI incompatibility - web
services are expected to be crashy bugfests, which is why we still mainly
use them for cases where relatively high failure rates (regardless of
cause) are an acceptable outcome.

Honza's suggestion of making the three levels of tagging (ruby, ruby-22,
ruby-22-centos7) available makes sense to me, as that puts the control in
the hands of the end user - when "centos/ruby-22" switches to
"centos/ruby-22-centos8", folks will be able to see the userland has
changed, even though it will likely still work with a centos7 kernel.

Cheers,
Nick.

-- 
Nick Coghlan
Fedora Environments & Stacks
Red Hat Developer Experience, Brisbane

Software Development Workflow Designer & Process Architect
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/sclorg/attachments/20151022/2f8a66cd/attachment.htm>


More information about the SCLorg mailing list