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.
- 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...).
- 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. :)
- 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.
- 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.