On Thu, Oct 31, 2013 at 11:26:25AM -0400, Josh Boyer wrote: > > Case 1 is easy -- no kernel, no problem. > Or, perhaps more accurately, that case is covered by either someone > else's kernel (which is SEP), or the standard kernel found in > Workstation and Server. Yes. > > 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. > I'm going to be blunt. VirtualBox and VMware aren't really focal > points for the kernel team, for exact opposite reasons. VirtualBox Yeah, that's exactly why I put "with priority to the first two". I'm totally happy with making that statement stronger / more clear. > > 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". > By which you mean admins manually (or via some tool like > puppet/chef/ansible) installs the subpackage, correct? Not "we create > a special cloud image with the drier subpackage already included". Probably manually, but I think we're still working that out as part of our overall direction. > > 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. > OK. I literally have no idea how this is different from a minimal > server install, so understanding that would be good. One difference is provisioning via an image vs. anaconada + kickstart. > Feel free to CC me. I'm subscribed to the cloud list now, but I can't > say I'll have time to fully pay attention to it. Please drag me (or > someone else on the kernel team) into specific things if you think you > need to. Thanks. We will take you up on that. > > Main drivers are network traffic, provisioning speed, and density. With > > probably a smidgen of marketing thrown in. > So the thinking is smaller size means less to transfer, faster to > boot, cheaper to store? I can see the first one. The second one is > mostly either going to be in the noise range or just false. The third > one I don't buy. Less to transfer is the one that's probably always going to be a meaningful issue, at least in our lifetimes. Size affects provisioning time because depending on the iaas software, the image is often be completely copied to a new file possibly on a different filesystem. Or on a different machine. This could be considered a subset of 'network traffic' in some ways, but I'm separating it out because the first includes things like "we don't want to have a Fedora image available by default in $iaasdistro because it's too big to be part of a normal install". I agree that density is probably the least important because in situations where that's a big concern there are other ways to address it (like deduplication). Anyone else feel free to chime in if I'm off-base here. :) > Now that's all basically image (as in file) size. What about runtime > overhead of the kernel? The server group is likely going to want > things like NR_CPUS to be larger than it is today, which incurs some > runtime memory usage overhead. It isn't huge, but it would be good to > know what common provisioning is in the cloud environments you're > targeting in terms of memory. Good question and I don't have a ready answer. Will keep this in mind as we go through the PRD process. -- 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
