ref: Create separate kernel and module images

[Callisto13]

Closes #31 , part of #49

This commit moves the kernel image out of the flintlock/ subdir and splits the kernel image into two: one containing just the binary, the other just the modules.

The sequence works like so:

• builder creates a starting point image from Ubuntu, installing packages etc.
• base uses builder, pulls and compiles the kernel, then saves the modules and the binary in a scratch image. I have kept this image under the old flintlock-kernel name with modules and the binary to maintain backwards compatibility.
• modules and bin use base and simply copy the things they need into a scratch image.

The images produced are:

• kernel-builder
• flintlock-kernel (kept the same for backwards compatibility)
• kernel-bin
• kernel-modules

[Callisto13]

Validated cluster works with:

rootVolume:
  id: root
  image: "docker.io/claudiaberesford/capmvm-k8s-os:1.23.5"
kernel:
  filename: "boot/vmlinux"
  image: "docker.io/claudiaberesford/kernel-bin:5.10.77"
volumes:
- id: modules
  image: "docker.io/claudiaberesford/kernel-modules:5.10.77"
  mountPoint: /lib/modules/5.10.77

[richardcase]

How would we slot the CloudHypervisor kernel into this re-organised structure? It requires different options to be enabled and so it would require a different kernel/modules images

[Callisto13]

How would we slot the CloudHypervisor kernel into this re-organised structure? It requires different options to be enabled and so it would require a different kernel/modules images

I planned to punt that to my stretch goal of using something like Packer to build our images instead. From what I see it provides an easier way of reusing modules of build parts into a matrix so we don't have to dupe things. If not that, I can split what we have further into as many reusable parts as possible and have like kernel/firecracker and kernel/cloudhypervisor subdirs:

# all off the top of my head
- kernel
  - builder
  - common base elements
  - firecracker
    - configs 
    - modules
    - bin
  - cloud hypervisor
    - configs
    - modules
    - bin

which is fine, at least better than it was now that we don't have OS images dependent on the kernel side of things.

but yeh i did ignore anything under experimental and perf for now 😜

[Callisto13]

@richardcase do you want me to factor in experimental images as part of this pr or can i leave it for the next one?

[richardcase]

@richardcase do you want me to factor in experimental images as part of this pr or can i leave it for the next one?

Lets leave it as a follow-up PR.