Modular Kernel Packaging for Cloud

[Sandro "red" Mathys]

On Thu, Mar 6, 2014 at 12:08 AM, Josh Boyer <jwboyer at fedoraproject.org> wrote:
> On Wed, Mar 5, 2014 at 9:59 AM, Gerd Hoffmann <kraxel at redhat.com> 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