Open Stack

On Wed, 6 May 2020 14:11:48 +0800
Peng Tao <tao.peng at linux.alibaba.com> wrote:

> On 2020/5/6 13:25, Ariel Adam wrote:
> > 
> > On Wed, May 6, 2020 at 5:37 AM Peng Tao <tao.peng at linux.alibaba.com 
> > <mailto:tao.peng at linux.alibaba.com>> wrote:
> > 
> >     My main concern about making guest kernel behave like the host
> >     kernel is
> >     that we might lose the ability to have a customized/optimized kernel
> >     just for container use case. There are a lot of kernel config options
> >     that are not going to be useful for container workload. So instead of
> >     just using the host kernel (for kata containers), I would suggest just
> >     using a minimal guest kernel as a basis and start adding new config
> >     options/modules as we identify new needs. And that is what we have been
> >     doing for Kata Containers in the past years.
> > 
> > Production wise there is a lot of value in having the same kernel on the 
> > host and the guest.
> > For example, taking a workload that has been run as a vanila container 
> > and then running it on a kata container could require a 
> > testing/certification process from scratch if the host/guest kernels are 
> > different.
> > Kernel CVEs would also be better managed if the host/guest kernels are 
> > the same.
> >   
>  From production experience, it is much easier to upgrade a guest kernel 
> than waiting for the host kernel to be upgraded. So I would suggest that 
> we do not bind Kata Containers kernel to a host's running kernel.

I think nobody is suggesting that they should be forcefully bound, but
still I see that usage as a very reasonable possibility (especially for
the reasons Ariel mentioned), and that already works to a very good
extent.

> Also feature-wise, we can use a newer kernel to run Kata Containers on 
> hosts that are running older kernels. So users running their good old 
> kernels can still make use of new kernel features with Kata Containers.

Well, there is actually a reason why they're running older (or newer!)
kernels, and that might apply to kata-runtime as well.

> And it makes sense to ship the same kernel for different distributions 
> in order to provide same user experience. And we only need to validate 
> and maintain one guest kernel for all distributions, which is much 
> easier than validating each kernel for each distribution version.

While I understand the reasoning behind this, it won't apply in every
situation. For example, if there's a security flaw in the kernel, this
would have the obvious drawback of requiring two packages (from a
distribution perspective) to be upgraded at the same time. There are
specific advantages and degrees of consistency both ways.

Also mind that Kata Containers doesn't really ship a kernel (neither
binary nor source). It ships (useful!) configuration fragments and a
script, but you can't control the compiler or the toolchain, or even
whether "-g nvidia" or "-g intel" is passed to build-kernel.sh, so,
while the scripting undoubtedly takes some burden off the testing
effort, I don't see much value going beyond that. This is not the kind
of "validation" a distribution does -- which by the way makes perfect
sense to me. Let the distribution do that :)

-- 
Stefano