Bug 1091097 - 9p kernel module(s) needed in kernel-default-base for kubic development environment
9p kernel module(s) needed in kernel-default-base for kubic development envir...
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
Current
Other Other
: P1 - Urgent : Normal (vote)
: ---
Assigned To: E-mail List
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-04-26 14:47 UTC by Maximilian Meister
Modified: 2019-06-17 11:25 UTC (History)
8 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maximilian Meister 2018-04-26 14:47:22 UTC
to inject our velum-development image and the source code for salt/velum/container-manifests we need to have the kernel modules for the 9p filesystem present (9p, 9pnet, 9pnet_virtio)

this enables us to work on local git clone(s) and see changes directly in kubic
Comment 1 Jiri Slaby 2018-04-27 13:18:29 UTC
Tumbleweed has these already:
CONFIG_NET_9P=m
CONFIG_NET_9P_VIRTIO=m
CONFIG_NET_9P_XEN=m
CONFIG_NET_9P_RDMA=m

I.e.:
/lib/modules/4.16.2-10.ge881e16-default/kernel/fs/9p/9p.ko
/lib/modules/4.16.2-10.ge881e16-default/kernel/net/9p/9pnet_xen.ko
/lib/modules/4.16.2-10.ge881e16-default/kernel/net/9p/9pnet_virtio.ko
/lib/modules/4.16.2-10.ge881e16-default/kernel/net/9p/9pnet_rdma.ko
/lib/modules/4.16.2-10.ge881e16-default/kernel/net/9p/9pnet.ko


So what do you need to change exactly?
Comment 2 Maximilian Meister 2018-04-27 13:46:18 UTC
(In reply to Jiri Slaby from comment #1)
> Tumbleweed has these already:
> CONFIG_NET_9P=m
> CONFIG_NET_9P_VIRTIO=m
> CONFIG_NET_9P_XEN=m
> CONFIG_NET_9P_RDMA=m
> 
> I.e.:
> /lib/modules/4.16.2-10.ge881e16-default/kernel/fs/9p/9p.ko
> /lib/modules/4.16.2-10.ge881e16-default/kernel/net/9p/9pnet_xen.ko
> /lib/modules/4.16.2-10.ge881e16-default/kernel/net/9p/9pnet_virtio.ko
> /lib/modules/4.16.2-10.ge881e16-default/kernel/net/9p/9pnet_rdma.ko
> /lib/modules/4.16.2-10.ge881e16-default/kernel/net/9p/9pnet.ko
> 
> 
> So what do you need to change exactly?

i need it as part of the kubic tumbleweed qcow images https://download.opensuse.org/repositories/devel:/CaaSP:/images/images/

not sure how they're derived from tumbleweed, but those images don't contain the kernel module(s)
Comment 3 Fabian Vogt 2018-04-27 13:54:41 UTC
Kubic uses kernel-default-base as requested, so it needs to be mentioned in supported.conf.
Comment 4 Jiri Slaby 2018-04-29 09:19:47 UTC
(In reply to Fabian Vogt from comment #3)
> Kubic uses kernel-default-base as requested,

Requested by whom? Why don't you just use kernel-default?

Neither SLE has 9p in -base and I am not much in favor of diverging.
Comment 7 Michal Kubeček 2018-04-30 08:33:05 UTC
(In reply to Fabian Vogt from comment #5)
> Thorsten. kernel-default-base is MUCH smaller than kernel-default, which is
> very helpful for VM images.

While I understand the logic, this trend of hijacking of the -base subpackage
(this is not the first such request, not by far - we already added e.g. most
of netfilter related modules) is a bit disturbing. Perhaps it's time to think
about a proper solution. What comes to my mind is

  (a) well defined subset of kernel modules that would go into a subpackage
      tailored for minimal VM images
  (b) a solution which would allow cherry picking modules for a particular
      VM image based on its purpose (so that the set wouldn't have to be the
      same for all images)

I'm aware that neither is likely to be done for SLE15 GA but it would be nice
to agree on a proper solution so that we could stop the stream of "hey, we
also need this module in -base" requests eventually (let's face it, this 9p*
stuff is already _very_ far from what -base is/was supposed to be).
Comment 8 Thorsten Kukuk 2018-04-30 14:21:14 UTC
If we speak really about images where we use kernel-default-base, the request is invalid. The virtualisation images are not for development and debugging, they are for customers who need a minimal footprint and easy way to deploy.
For internal we can build images with kernel-default.
Adding all helpful modules to kernel-default-base makes it unuseable as a small kernel for virtualisation environments, where you don't want over 600MB installed if 67MB are enough.
Comment 9 Maximilian Meister 2018-05-02 07:05:26 UTC
in general it's only an issue for a kvm development image

but this doesn't apply to other images (XEN, vmware, OpenStack, HyperV ...) only to kvm, as 9p is the recommended way to share data from the host with the vm (http://www.linux-kvm.org/page/9p_virtio)

would it make sense to build a dedicated kvm-development image which just has the different kernel? it would only be used by developers working on kubic, and not production environments
Comment 10 Fabian Vogt 2018-05-02 07:25:43 UTC
(In reply to Thorsten Kukuk from comment #8)
> If we speak really about images where we use kernel-default-base, the
> request is invalid. The virtualisation images are not for development and
> debugging, they are for customers who need a minimal footprint and easy way
> to deploy.
>
> For internal we can build images with kernel-default.
> Adding all helpful modules to kernel-default-base makes it unuseable as a
> small kernel for virtualisation environments, where you don't want over
> 600MB installed if 67MB are enough.

IMO kernel-default-base should be the same as kernel-default but just exclude
support for physical hardware. Anything else is just asking for trouble.
I can definitely see use-cases for 9pfs in production.

(In reply to Maximilian Meister from comment #9)
> in general it's only an issue for a kvm development image
> 
> but this doesn't apply to other images (XEN, vmware, OpenStack, HyperV ...)
> only to kvm, as 9p is the recommended way to share data from the host with
> the vm (http://www.linux-kvm.org/page/9p_virtio)
> 
> would it make sense to build a dedicated kvm-development image which just
> has the different kernel? it would only be used by developers working on
> kubic, and not production environments

There could be a new image type with kernel-default, which would then also run on physical hardware.
Comment 11 Michal Kubeček 2018-05-02 07:37:28 UTC
(In reply to Fabian Vogt from comment #10)
> IMO kernel-default-base should be the same as kernel-default but just exclude
> support for physical hardware. Anything else is just asking for trouble.
> I can definitely see use-cases for 9pfs in production.

Sounds like you are still assuming kernel-*-base subpackage was designed for
use in general purpose VMs. AFAIK this is not true, even package description
says something very different. What you want is rather closer to -ec2 flavor
we have had earlier or kvmsmall config recently introduced in newer branches
(it is meant for developer use but it's probably closer to your idea what
-base subpackage should be than actual -base). Therefore my suggestions from
comment 7.
Comment 12 Fabian Vogt 2018-05-02 07:49:11 UTC
(In reply to Michal Kubeček from comment #11)
> (In reply to Fabian Vogt from comment #10)
> > IMO kernel-default-base should be the same as kernel-default but just exclude
> > support for physical hardware. Anything else is just asking for trouble.
> > I can definitely see use-cases for 9pfs in production.
> 
> Sounds like you are still assuming kernel-*-base subpackage was designed for
> use in general purpose VMs. AFAIK this is not true, even package description
> says something very different. What you want is rather closer to -ec2 flavor
> we have had earlier or kvmsmall config recently introduced in newer branches
> (it is meant for developer use but it's probably closer to your idea what
> -base subpackage should be than actual -base). Therefore my suggestions from
> comment 7.

Yes, the best option is IMO to have a hand-pickable kernel with modules sorted into independent groups. That would allow arbitrary combination of flavors.
It also makes it possible to install some additional modules when needed instead of including them in every image just in case.

However, we can't do that now, so my suggestion for the near future is to make kernel-default-base complete enough to allow its use in all situations on virtual hardware.

Both options avoid having to open a bug with the same discussion for every module ;-)
Comment 13 Jiri Slaby 2019-02-07 08:13:52 UTC
I'm not sure who should be assignee here. Perhaps Michal Suchanek's solution will fix this?
Comment 14 Michal Suchanek 2019-02-07 08:50:35 UTC
Once FATE#326579 is merged you can change content of kernel-default-base.

See SLE15 SP1 kernel-default-base for example.

If you need different kernel-default-* it needs to be added to the list in kernel-source repo first.
Comment 15 Jiri Slaby 2019-06-17 11:25:30 UTC
So this looks like fixed by subpackages...