On Thu, Mar 6, 2014 at 12:08 AM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > On Wed, Mar 5, 2014 at 9:59 AM, Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: >> >> Hi, >> >>> I'm not overly thrilled with having multi-tiered driver packages. >>> That leads to major headaches when we start shuffling things around >>> from one driver package to another. The current solution I have >>> prototyped is a kernel-core/kernel-drivers split. Here "core" could >>> be analogous to "cloud", but I imagine it will be useful for other >>> things. People wanting to do PCI passthrough can just install the >>> kernel-drivers package. Fair enough, agreed. We might need to eventually revisit this decision if SRIOV or graphic cards computing really take off and people complain. But right now, it's edge cases. >> Agree, I don't think it makes much sense to split things into many small >> pieces. >> >>> - Do you need/want a firewall (requires iptables, etc)? While not strictly necessary (the IaaS usually puts a firewall right in front of the instance / guest), I think we do want to allow each and everyone to optimize their security needs. The local iptables also has way more capabilities than the provided one offers. >> >> I'd say yes by default, but being able to remove it might be useful >> (kernel-netfilter subpackage)? > So you agree multi-tiered subpackages is a bad idea, but then you > propose a netfilter specific subpackage? ... Probably not. They'll > likely just be in kernel-core. > >>> - Do you need/want NFS or other cloudy storage things (for gluster?)? Usually, you just attach additional volumes when you need more space but, particularly in private clouds, people do all kinds of weird things to get their data from here to there so I think we want all storage options. Also, support for every (major) filesystem that you could put on additionally attached disk drives. >> I'm personally using NFS for host/guest filesystem sharing, so I'd vote >> yes. >> >>> - Do you need/want openvswitch? >> >> I think no. That's a host side thing and this is about the guest >> kernel, right? > > Nested virt? I dunno, it was mentioned at one point so I thought I'd > bring it up for discussion again. There are use cases that use OVS but I'd say they are rare. And nested virt is even rarer (particularly since Docker helped pushing lxc). So I don't think we want OVS in the guest image. >>> The list of modules I have in my local rawhide KVM guest is below. >>> The snd_* related drivers probably aren't necessary. The btrfs and >>> things it depends on can be ignored (unless you plan on switching from >>> ext4). As mentioned above, btrfs could be used on user-attached drives so keep that in there. But the root disk will be in line with the other Fedora products. >> Depends on what is targeted. Strictly cloud? Or also someone running >> Fedora as a guest in virt-manager / boxes? > > I'm of the opinion the latter is probably what we should shoot for. > It's going to be the broadest target that is still reasonably small. "Guest in virt-manager" is not part of our PRD, so it's not actually required. But as Matt mentioned, it's incredibly valuable for testing purposes. That should be a good enough reason to include something reasonably small. > >> I'd tend to include drivers for pretty much everything qemu can emulate. >> >> <snip-snap detailed module talk> > > OK. Was planning on that already. Make it so :) -- Sandro _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
