On 08/06/15 12:47, Andrew Stuart wrote:
Can you be more specific about what you are doing? rumprun/rumpconfig already
automatically mounts specified file systems.
I might be misguided or off track here so please feel free to set me straight.
I’ll describe what I’m trying to achieve and would value feedback. I don’t
know exactly how rump works, so it might actually do some or all of this now.
The core idea I’m working to is that it should be possible to take a kernel and
run it on a cloud provider (EC2 in the first case as it is the primary player
in the field at the moment).
kernels are naturally one of three types:
type 1: kernel has no need for a file system. No block device required.
type 2: kernel has need of a small number of read only files, total size <
total RAM. No block device required.
type 3: kernel has need of access to an abitrary set of files. Block device
required. In some cases read only, in some cases read/write access is required.
From a deployment perspective the most easy to deploy is kernel types 1 and 2
because no block device needs to be configured, attached and managed.
I don't see a benefit in handling them as different cases. Since you
need to handle 3 anyway, you're just adding complexity without benefit.
For limping along and trying to figure things out, it's nice to be able
to start from "1". The final launch procedure should simply always be
prepared to handle "3".
For kernel type 3, things become more complex because we need to attach one or
more block devices/file systems which need to be pre-formatted. Ideally somehow
if a kernel is started up with 1 or more block devices attached, the kernel
would detect the block device, detect the file system format and mount the file
systems without needing to receive commands instructing it to do so.
That's how it already works. See how the config json changes when you
specify -b arguments to rumprun. Also observe the difference in how
that works for the iso target and e.g. the xen or kvm targets. Ideally,
we'd have one image with a partition table, but hacking it together that
way was quicker for now. Anyway, I'd say you don't need to worry about
partition tables, just reuse the hack that "iso" uses.
