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(a)fedoraproject.org>