Cloud product kernel requirements

[Matthew Miller]

On Wed, Oct 30, 2013 at 10:07:46AM -0400, Josh Boyer wrote:
> The kernel team has heard in the past that the Cloud group would like
> to see something of a more minimal kernel for usage in cloud images.
> We'd like to hear the requirements for what this smaller image would
> need to cover.

I think the main four cases are:

  1. Running inside a container
  2. Running as a typical guest in a private or public cloud
  3. Running as a special guest in the same
  4. Running on bare metal (as compute node or possibly host node)

Case 1 is easy -- no kernel, no problem.

Case 2 is everything needed to boot and get network, console output, and
normal storage under KVM, Xen (especially as used in EC2), VirtualBox, and
VMware. (With priority to the first two.) This *could* be split further,
making a distinction between cloud providers, but there's diminishing
returns for effort.

Case 3 covers things like PCI passthrough or running a remote desktop where
you want virtual sound card support. For this, I think it's perfectly fine
to say "add the extra drivers pack". 

Case 4 could use a bit more discussion. *Mostly*, I think we can either say
that this is the same as case 3 or that we will just use whatever Fedora
Server does in this case (if different). However, I know oVirt Node (and
probably also OpenStack node) is concerned with image size on bare metal.
This would be a good time for anyone interested in that as a focus to chime
in.


More responses below....


[...]
> various things) is about 11MB.  Drivers can be trimmed to a degree,
> but please keep in mind that the kernel is already relatively small
> for the functionality it provides.  For example, it is not much bigger
> than glibc-common (119MB).

Most of that in glibc-common is translations, so that's one of the other
things we're working on tackling.

> 1) We're mostly talking about packaging here, not building a separate
> cloud kernel package or vmlinux.  The kernel team really wants to have
> a single vmlinux across the 3 products if at all possible.  We can't
> scale to much else.

Yeah. That also has ripple-effect benefits beyond just the core kernel team
(QA, documentation...).

> 2) What usecases is the cloud image going to cover?  E.g. is it just
> virtio stuff, or will it also fit PCI passthru (which then requires
> drivers for those PCI devices)?

We'll need to develop this in more detail beyond the four general cases
above. Possibly one of our first trac tickets. :)


> 3) What are the common provisioning requirements that are driving the
> size reduction?  (See comment about glibc-common.

Main drivers are network traffic, provisioning speed, and density. With
probably a smidgen of marketing thrown in.

>  I would think
> change is needed in multiple packages, not just the kernel.)

Yes -- kernel, docs, i18n, python, and then various small changes which add
up. Not necessarily in that order -- docs and i18n are actually bigger, and
because they apply in the container case, more important.

> 4) Other "cloudy" stuff that I'm entirely unaware of that might be
> relevant.  Explain it to me like I'm a child.

I hope the above is a good start, and I hope others can chime in what what
I've missed.



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm at fedoraproject.org>