Hi,
For a while I've been talking about how the rumpbake-rumprun axis is not
quite right. I think it's now clear, at least to me, that the problem
stems from the launch tool being modelled after Docker. It was a smart
decision at the time, but the problem we've discovered since is that it
was made with too little case data (Xen xl toolchain only). You start
from somewhere reasonable-looking, you learn, and now we've learned that
we have too many targets completely unlike Docker. I'd even go so far
as to state that "Docker-like" is the special case. What goes wrong is
that the "rumprun" tool assumes it can both create a configuration and
launch the guest. The former is always true (though embedding the
config into something launchable is sometimes awkward), the latter is not.
So let's try to figure out how to fix the situation. So what do we
actually want?
1: a distributable format which does not require the toolchain to launch
(what rumpbake currently gives you)
2: a mechanism to configure the runtime behaviour of the distributable
format (what the rumprun tool currently does)
3: a mechanism to easily launch the result of 1+2 *where available*
(what the rumprun tool does for xen+kvm+qemu)
4: a mechanism to "specialize" the distributed format, e.g. "baked in
root files" or even including "2" (to enable running without block storage)
So then to the adjustment proposals.
I don't think there's any reason to touch "1". We need some further
adjustments for component management a la rumpbake.conf, but that's
mostly orthogonal.
Ok, that was easy, let's move to "2", config creation. There are
actually 2 different configs, the Rumprun runtime config and the config
of whatever you launch on. We can't always control the latter from
software, consider e.g. the case where you're launching on an embedded
system, so this bit is only about the Rumprun config. We now use a json
config. I'm thinking that the best option is to not provide a config
generating tool at all, simply polish the json format spec and be happy
with it.
Then, "3" or launching. Now, there needs to be a congruence between
your config from "2" is and what you launch on. The current rumprun
tool sort of attempts to help you there, but with anything except a
trivial setup you need to know what you're doing anyway, e.g. "-I
,,'-net tap,ifname=tap0" constructs and so forth. So the tool is not
*really* catching you because it cannot read your mind. Do we need a
quasi-abstracting tool? I'm going to say "no". The real eye-opener
here for me was working on EC2. We simply have no way to sensibly
abstract the 3 billion toggles available via EC2. Even for trivial
systems like xl.conf (when compared to EC2), if you know xl.conf you'll
just have to learn a second syntax to do what you already know. If you
don't know xl.conf, we can provide an example or two. Not sure if we
should provide some case-specific helper scripts, though nothing which
pretends that everything is the same, hides power and throws off people
who'd know how to use the relevant backend tools.
After some thinking, the solution to "4" is obvious. They are simply
components. Want a non-default /etc? Use a different component (see
now why rumpbake.conf needs more flexibility/power?). Want to include
the config too? Again, a component. (We probably need some tools to
generate the components, but that's an entirely different discussion)
Thoughts? Take your time, this is not a rush job, but let's say would
be nice to have the rototill done by or latest in October.
