Re: rumpbake support for baked-in rootfs
- From: Antti Kantee <pooka@xxxxxx>
- To: rumpkernel-users@xxxxxxxxxxxxx
- Date: Mon, 08 Jun 2015 05:27:14 +0000
On 05/06/15 16:03, Martin Lucina wrote:
rumpbake now accepts multiple '-R PATH' options. Each -R option adds the
contents of PATH to the root filesystem for the unikernel we are baking.
1) I'd like to use this to include a stub /etc directly in the unikernel
image *by default*, so that my rump-* "packaging" for nginx and other
software does not need to include its own stub /etc. This is also why
multiple -R options are allowed, so that you can add to / override the
default contents if you wish.
It would indeed be nice to have some usable /etc by default.
3) It begs the wider question of what to do with "rumprun iso". This
currently produces an ISO image with a "root" filesystem of its own, mostly
so that it can get at the rumpconfig data to configure the unikernel. Also,
"rumprun iso" does not actually *run* anything, so it seems like this
functionality is in the wrong place.
With my support for a baked-in rootfs the extra "root" filesystem for
rumpconfig is no longer needed, however the "make an iso" functionality
would have to be done in/depend on rumpbake.
Well, not only the config, but also the data. I did create isos with
large data partitions for the mpg123 unikernel, and anything that loads
the data into memory as part of the bootstrap process is not a
replacement. It's not hard to imagine that the same size concern would
apply also to e.g. web servers and databases, so you really need a
runtime block device driver to support the general case.
Thoughts?
I don't think -R should be committed without more thought.
We need to agree on the big picture first before we debate details. The
toolchain is now:
1) compilation
2) baking to produce a deployable image
3) deployment
Compilation is more or less finalized (at least as soon as someone does
the rename ;) so we can thankfully leave it out of the discussion.
As far as it seems logical to me in my current state of
mind/understanding, the data and code should be specified in step 2.
Configuration (e.g. /etc/passwd, keys, etc.) should be specified in step
3, not step 2. With that in mind, adding -R to step 2 seems like the
wrong place.
It might be useful to crunch out a few scenarios. I can do some in a
few days.
Other related posts:
