Re: Requiring Linux 3.2, again

[Carlos O'Donell <carlos at redhat dot com>]

On 05/03/2017 07:26 AM, Joseph Myers wrote:
> When we discussed moving to Linux 3.2 as the minimum kernel version 
> requirement for glibc over a year ago, concerns were expressed about how 
> this would affect some containers 
> <https://sourceware.org/ml/libc-alpha/2016-02/threads.html#00173> and we 
> only had consensus for a change for architectures other than x86 / x86_64.
> 
> Now that more than a year has passed and 2.6.32 has been EOL for a year 
> more, do people still care about running distributions from late 2017 or 
> later on such old kernels, or can we now move to a 3.2 minimum globally?
 
We're fine going to linux 3.2.

TLDR;

At a high level I worry about container technology (regardless of the
choice of framework around namespaces) and the pressure we apply to users
by moving glibc to require a newer kernel.

Every time we move glibc to require a newer linux kernel that creates an
inflection point where users have to upgrade their container host to run
the newer distribution containers.

I don't have any good data about what this looks like and the Parallels/OpenVZ
is a singular data point, and not very conclusive in my opinion, but we took
a conservative approach and waited, and that's probably right.

Looking at the OpenShift Origin server as another example, it already requires
RHEL 7.3 (linux 3.10), so I see no problem there. Similarly Project Atomic also
has as a requirement either CentOS7 or Fedora25, both of which are linux 3.10
or newer. The technology is moving quickly on the container host front.

What about the next step though? And the next? Moving beyond linux 3.10 would
mean that any future RHEL which is rebased to the newest glibc would not be
able to easily run in a container on RHEL 7 using a RHEL 7 kernel. 
Taking note that RHEL7 has support until 2024 at a minimum.

Do we harm the adoption of new glibc versions because of container requirements?

This isn't a new problem, and I've been educating people as much as I can about
glibc's minimum kernel requirements. Perhaps we'll succeed at embedding in the
common knowledge that you need a newer host kernel than the containers guests
expect and just plan for that to be the case that gives you the least problems
and the best compatibility overall (short of running with an exact match of
expectations).

-- 
Cheers,
Carlos.