Re: Modular Kernel Packaging for Cloud

[Josh Boyer]

On Wed, Mar 5, 2014 at 9:59 AM, Gerd Hoffmann <kraxel(a)redhat.com&gt; 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.
>
>  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)?
>
>  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?)?
>
>  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.

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

>  I'd tend to include drivers for pretty much everything qemu can
> emulate.
>
> > uinput                 17708  1
>
>  spice guest agent uses this.
>
> > bluetooth             445507  5 bnep
> > cfg80211              583354  0
>
>  bluetooth+wireless are not needed, dunno why they are loaded. 
Me either.  I'm guessing because systemd/NetworkManager on my KVM
guest auto-loads them.

> > snd_hda_codec_generic    66943  1
> > snd_hda_intel          56588  4
>
>  For the qemu HDA soundcard.  Should be included if desktop usecase
>  should be covered too.
>
> > qxl                    74078  2
>
>  gpu driver.  There are also cirrus + bochs-drm for qemu.
>  vmware vga has a drm driver too.  They should be included.
>
> > ata_generic            12910  0
> > pata_acpi              13038  0
>
>  IDE.  Needed.  Qemu can emulate AHCI too, should be included (but I
>  think that is =y anyway).
>
>  Qemu can emulate a bunch of SCSI HBAs.  Don't think we need the drivers
>  for them (except virtio-scsi).  vmware emulates SCSI HBAs too.  pvscsi
>  should be included.  Dunno about the older ones, there was for example
>  some buslogic emulation in older vmware workstation versions ...
>
>  USB: Qemu can also emulate uhci + ehci + xhci, should be included.  Also
>  usb-storage and generic hid support (for the usb tablet).  IIRC most of
>  this is =y anyway.
>
>  NIC: e1000, rtl8139 (qemu), tulip (hyperv), dunno about vmware.  qemu
>  can also emulate a bunch of other nics such as ne2k, but I think those
>  are not relevant in practice and not needed.
>
>  Of course all paravirtual drivers should be included too, i.e.
>    * all virtio (for qemu)
>    * all xen frontend (for xen, the backend drivers are for the host
>      side and are not needed in the guest).
>    * all hyperv (for hyperv) 
OK.  Was planning on that already.

josh

Modular Kernel Packaging for Cloud

[Bruno Wolff III]

On Wed, Mar 05, 2014 at 10:08:04 -0500,
   Josh Boyer <jwboyer(a)fedoraproject.org&gt; wrote:
> 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. 
Couldn't the planned module provides allow something like this to work 
without worry much about which modules are in which packages? netfilter 
could juts require the modules it needs and it would pull in and extra 
kernel module packages that are needed.

Modular Kernel Packaging for Cloud

[Josh Boyer]

On Wed, Mar 5, 2014 at 10:51 AM, Bruno Wolff III <bruno(a)wolff.to&gt; wrote:
>  On Wed, Mar 05, 2014 at 10:08:04 -0500,
>    Josh Boyer <jwboyer(a)fedoraproject.org&gt; wrote:
> >
> >
> > 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.
>
>
>  Couldn't the planned module provides allow something like this to work
>  without worry much about which modules are in which packages? netfilter
>  could juts require the modules it needs and it would pull in and extra
>  kernel module packages that are needed. 
Possibly.  But it's not just the installed system to be taken into
account.  Every additional subpackage and list is something that needs
to be maintained and further complicates the kernel.spec file.  It
adds to testing all the combinations of kernel packages and
subpackages being installed (or not) and upgraded, etc.  For the sake
of the kernel maintainers, keeping it limited is probably a good idea.

And honestly, a firewall in today's world seems pretty darn "core" to me
anyway.

josh

Modular Kernel Packaging for Cloud

[Matthew Miller]

On Wed, Mar 05, 2014 at 10:08:04AM -0500, Josh Boyer wrote:
>  > 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. 
I agree that this is valuable, because it lets the same image be used for
testing locally.

-- 
Matthew Miller    --   Fedora Project    --    <mattdm(a)fedoraproject.org&gt;

Modular Kernel Packaging for Cloud

[Sandro "red" Mathys]

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