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@xxxxxxxxxxxxxxxxx> _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
