On Wednesday, 21.10.2015 at 14:39, Antti Kantee wrote:
> The problem it was trying to solve was developers doing quick iteration.
> Remember, *you* were concerned about that developer convenience factor going
> away. If now two weeks later nobody is interested in iteration anymore then
> it makes complete sense to not have such a tool. If so, the thing that
> makes *the problem* go away is the attitude change. Shifting goal posts is a
> different way of reaching the goal (and sometimes a completely valid one).
> In this case shifting the posts would probably simplify a lot of things,
> like I already wrote in the rumprun-rumpbake-axis thread.
>
> Here's the relevant mail, if someone wants to refresh their memory:
> https://www.freelists.org/post/rumpkernel-users/fixing-the-rumpbakerumprun-axis,4
Coming back to this thread after meditating on it and learning a lot more
data points, especially while putting together the "Unikernels, meet
Docker" demo for DockerCon, where I deliberately did not use the "rumprun"
or "rumprun-launch" tool [1] ...
Antti, re-reading your email from the rumprun-rumpbake-axis thread
referenced above:
> Without a developer tool, the documentation is simply "really do it".
> Developers are smart, they can figure out what aliases/oneliners they
> want from "this is how it works". They can't figure it out from "run
> script and then some magic happens" without tearing the script into
> pieces first.
Agree. In the spirit of "removing all magic", your "rumprun-launch qemu" is
equivalent to:
qemu-system-x86_64 -kernel wopr.bin \
-append "$(rumprun-config-qemu wopr.json)" \
[QEMU/KVM parameters here]
With "rumprun-config-qemu" being just "cat /dev/null "$@" | sed
's/,/,,/g'".
All magic gone, launching a rumprun unikernel under QEMU/KVM is now
as transparent as can be. So far so good, but ...
> ... is there really a case even for that version of rumplaunch? Why don't
> developers use the bundle method? Sure, it'll take half a second longer
> to iterate with bundle, but does it really matter?
... the case is PV Xen, which has no concept of booting a
"machine image", i.e. you always do "direct kernel boot". Furthermore, I
tried some more to replicate "xl create <stuff to get JSON config to domU
via command line>" and failed miserably (boring details elided).
So, for Xen *at least* the extra steps of:
1) Create domU paused
2) Write configuration to Xenstore
3) Unpause domU
are *required*.
> So does anyone care about the "quick iteration" going away? (I don't)
For QEMU/KVM it can definitely go away.
For PV Xen the answer is not as straightforward. For me it's more than just
"quick iteration", it's also about being able to easily launch a rumprun
unikernel with console in one command, run it from systemd or other process
manager, etc. If "rumprun" (for PV Xen) goes away, then these features
which I *currently use* also go away, with no replacement.
The conclusions that I'm leaning towards are:
1) We don't need rumprun{-launch} for QEMU/KVM. We can supply the
"rumprun-config-qemu" convenience script above since that's trivial.
2) "rumprun iso" should become "rumprun-bundle", and can gain support for
more filesystems/bundling schemes to provide ready-to-run "machine images"
suitable for GCE, EC2, etc.
3) It follows from the above that we document the JSON config spec fully,
including describing the method(s) for passing the config to the unikernel
on various platforms. I'm happy to start on this, since I've been wanting
to turn the current "internal" format into a proper specification anyway.
4) I don't know what to do about Xen PV. Options are:
a) Drop rumprun-launch for Xen and instead supply a trivial example
script and/or document the commands needed to launch a rumprun unikernel
manually on Xen, leaving developers to edit the script/commands as they
see fit.
This leaves me unhappy, but I can just keep using the old tool anyway
:-)
b) Keep current rumprun-launch tool but for Xen PV only, on the grounds
of Xen being "different enough" that it justifies having an extra tool
that does more magic.
Thoughts?
Martin
[1] See e.g.
https://github.com/Unikernel-Systems/DockerConEU2015-demo/blob/master/nginx/run.sh
