On Mon, Dec 19, 2016 at 5:46 AM, Florian Weimer <fweimer@xxxxxxxxxx> wrote: > > On 12/19/2016 11:25 AM, Daniel P. Berrange wrote: >> >> On Mon, Dec 19, 2016 at 11:19:06AM +0100, Florian Weimer wrote: >>> >>> Do we need to support running current Fedora releases in kernels which are >>> older than the initial Fedora kernel for that release? >> >> >> That is important if we wish to allow a Fedora container of version X >> to be run on a host with Fedora version X-N, for some N. Or equivalently >> allow a Fedora version X to run as a container on a non-Fedora host (Ubuntu/ >> RHEL/Debian/whatever) since they'll almost certainly have a different kernel >> version to what Fedora initially ships and that can't be assumed to be newer. > > > But this equivalence does not exist because Fedora quite aggressively updates kernel releases in maintained releases. The other distributions you listed do not do this. I'm confused why Fedora's kernel rebase policy impacts the desire to run Fedora containers on other distribution hosts. They are completely separate topics. It doesn't matter if e.g. Debian doesn't rebase their kernel during a major release. We'd still want Fedora containers to work there. >>> If yes, what are the kernel baselines? We can go back to releases earlier >>> than 3.2 on most architectures because that's the current glibc baseline >>> (except x86_64 and i386, where the glibc baseline is 2.6.32). >> >> >> To maximise container compatibility, we'd want to be quite conservative >> in kernel baseline version. > > > Is there any evidence we actually care about this? Like still supporting an *unpatched* 2.6.32 kernel on x86_64? I don't think we have a lot of test coverage for this. There is evidence we actually care about supporting RHEL kernels, as they are used in our infrastructure. Investigation into containerizing some of the Fedora services is on-going, and limiting ourselves to only Fedora hosts or very shiny kernels would shoot ourselves in the foot there. josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
