Re: rumpbake support for baked-in rootfs
- From: Martin Lucina <martin@xxxxxxxxxx>
- To: rumpkernel-users@xxxxxxxxxxxxx
- Date: Tue, 16 Jun 2015 11:36:26 +0200
On Monday, 15.06.2015 at 18:05, Antti Kantee wrote:
On 15/06/15 14:33, Martin Lucina wrote:
I've rebased the wip-rootfs branch against the latest master and re-pushed
it in case you need that. I'll write up plans for merging the baked-in
rootfs code to master shortly.
Let's think about if what you're proposing is acceptable in the
first place before making plans on how to merge it.
Ok. First of all, my immediate motivation for implementing this is
responding to and executing on user demand. The idea of baking a
filesystem into the kernel image has already been brought up on this list
at least twice as far back as April, see [1] and [2].
Further, I'd like to enable Andrew to get a useful unikernel working on AWS
*now*, the same for the Mirage folks who want to boot a demo Mirump
unikernel on eg. Virtualbox because they are using Macs for their
workstations.
As far as I could extract from your original proposal (and please
correct me if I'm wrong), the proposal includes the following
subpoints:
1) adds a default set of files which libc internally expects
My proposal provides a mechanism to enable adding a default /etc (or
anything else), but defining what goes in there is a theme for a separate
discussion. Having said that, at least mathopd, nginx and MySQL *require* a
minimal default /etc and one non-root user in order to work at all, so I
think adding the "stubetc" as a default /etc is not controversial.
2) adds support for a tarball-based "file system"
3) support for linking an arbitrary file system image into the binary
4) syntax for all of the above squashed into one flag
"1" is a great usability improvement.
"2" might be nice, though it might be nicer if it actually worked
like every other file system driver instead of just being randomly
hacked somewhere.
As was discussed in [1], NetBSD does not currently provide a suitable
filesystem driver. Hence my use of a Linux initrd inspired approach of
extracting a tarball to /. Of course the current implementation leaves much
to be desired (at the very least, it wastes memory since your data is in
there twice), however it is also minimal and works today.
I have no attachment to this particular *implementation*, in fact I'd be
the first to throw it out and replace with something like SquashFS.
"3" is, AFAICT, useful only when you can't have a block device.
What are such cases? I know Andrew used it for platform bootstrap,
but adding an entire mechanism to support a small phase in platform
bringup is out of the question.
Can't or don't want to. I can think of several scenarios where I don't want
a block device:
1) Cloud providers (AWS, etc.) only provide block storage in gigabytes, and
each cloud provider has their own specific mechanism for provisioning such
storage. I don't expect the former to change any time soon, and support for
the latter in rumprun is going to take some time to materialise, if at all
(worth a separate discussion about the scope of rumprun, not here).
Therefore, if I want to run a minimal and small[*] service as a rumprun
unikernel in the cloud *today*, and that service does not need any
persistent data, why should I bother with an (external) block device at all?
2) Expanding on Andrew's point about "ease of deployment" from a later
reply in this thread, the ability to have a single self-contained
image containing all code, data and configuration needed to run a service
is extremely appealing to many people. For example, the Mirage folks use a
deployment workflow based on exactly this [3].
Another important usability point for such self-contained kernels is that
they are extremely easy to migrate from "development and testing on local
laptop with KVM" to "deployment on $CLOUD". In fact, the only thing missing
for this to work right now is network device autoconfiguration by default
(separate discussion again).
3) For my own deployments, I want to use Xen as provided and supported by
the Linux distribution I run on my dom0, and I'd like my unikernels to boot
fast. Currently that rules out using image files for block devices as
booting a unikernel using such a block device takes seconds due to spawning
a new qemu instance (which I don't want either, even if it was fast!). I'm
sure this will get fixed eventually, but I can't wait months until such
fixes trickle down to production deployments of Xen. I can work around this
today by using LVM volumes, however a baked-in filesystem just makes it
much easier.
"4" leaves much to be desired. Why can you only add files but not
remove them? Why is the backing file system type hardcoded to
"tarball"?
I can make the implementation even more minimal and allow for including
only a single directory tree if it bothers you. The reason I implemented
multiple -R's was to provide a (granted, poor/minimal but working) ability
to accomplish:
rumpbake -R ...path/to/default/root -R data/ ...
ie. Give us the ability to provide a default /etc in the rumprun
repository.
I'm not sure what you mean by the second point about the backing filesystem
type being hardcoded to "tarball"? That seems like an implementation
detail.
How do you justify "2" and "3", and how do you plan to fix "4"?
Again, my main justification is responding to user demand and enabling
people to get things running *now* with a minimal amount of implementation
work on our side.
Of course there are tradeoffs to this approach, and you probably don't want
to run a MySQL database on an in-memory filesystem, but that doesn't mean
providing the option of doing so is a bad idea.
-mato
[1] "configuration" thread from April:
https://www.freelists.org/post/rumpkernel-users/configuration,7
[2] "Xen PV on AWS" thread from May:
https://www.freelists.org/post/rumpkernel-users/Xen-PV-on-AWS-was-Re-iso-target-for-rumprun-was-Re-file-system-access-on-cloud-instances,15
[3] "Deploying via Continuous Integration":
http://www.openmirage.org/wiki/deploying-via-ci
Other related posts:
