On 24/09/15 17:51, Martin Lucina wrote:
1) Rumprun developers (us), testers, application porters and generally
anyone who just wants to "try things out" on their laptop/handy server:
(For the sake of clarity, I'm going to dub the current rumprun tool
'rumplaunch', since the name is overloaded by the both the tool and the
unikernel project as a whole. Feel free to pick a better name.)
As I wrote above, I think that rumplaunch should stay but its scope
should be reduced to development, testing and deployment on a local
Xen/KVM/(bhyve, etc in future?) system. No such tool currently exists
and we need one simply to develop the rumprun unikernel!
If we reduce its scope and target audience, we can also improve the
abstractions provided:
- Provide a "template" network configuration for KVM/QEMU which users
can install. Such a configuration could be as simple as "create a
rumplaunch0 bridged network, run dnsmasq on it and NAT to the
outside world".
- With such a configuration in place, the *default* network setup for
unikernels run with rumplaunch becomes "just do DHCP". Bam, the
whole "-I ,,'-net tap,ifname=tap0" nonsense just went away.
No, it pushes the same configuration into a hidden template using
defaults which happen to work for you on your system. Even if tap0
works for me today, there's no saying it'll work for me tomorrow. "argh
where is that stupid config file?".
Do we also default to storing the config the raw /dev/sdb device (works
for my system today) and hide that toggle in the same template? No, we
don't, because it's equally absurd.
It was smart to try writing such a tool once. Seeing that it didn't
work, trying more or less the same thing twice is not quite as smart.
If you want to do custom stuff that the rumplaunch tool doesn't provide
for, you can always do it manually using the relevant backend tools (xl,
qemu).
Anyone who wants a custom launch tool for their use case can develop and
maintain it outside of the rumprun repo. If someone comes up with one
which works really well for a general enough [developer] audience, we
can evaluate its merits separately. The name of the game now is "stuff
works, is stable, and can be used as building ground", not "solve a
handful of special case problems perfectly".
The problem with including a not-so-generic tool is documentation: "do
this ... except if the defaults are not good enough, then do this ...
except if the general structure isn't good enough ... then really do
it". 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.
The only convenience factor I can see a universally shipped "instant
virtualization" launch tool providing is attaching the json config to
the launching instance. Something like:
rumplaunch /path/to/cfg.json xl [pass-through xl args]
rumplaunch /path/to/cfg.json qemu [pass-through qemu args]
However, ...
2) People who want to run rumprun unikernels on classic "full VM
hypervisors" today. This includes both desktop hypervisors such as
VirtualBox, VMWare Workstation and cloud hypervisors such as EC2, GCE or
Azure:
We should provide a 'rumpbundle' tool (again, tenative name) which
(ec2ivol problems notwithstanding) takes a rumprun unikernel, possibly
including application data and minimal configuration and spits out a
full machine image suitable for loading. Nothing else, i.e. we do not
attempt to actually perform the "import-register-run" dance for cloud
hypervisors.
This is more or less what the current "rumprun iso" and "rumprun ec2"
functionality already does.
... 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?
Serious want-to-launch-a-billion-instances users will no doubt have one
image and some network-side autoconfig depending on the MAC address (and
the exact details of that are out of our hands), so bundle is just fine
for them too.
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)
Agreed. So the work I did some time ago on baked-in-files, were it to
spit out a linkable component containing a MFS filesystem, would that be
a good start?
What do you mean "were it to spit out"? It was a parameter with weird
semantics to rumpbake, no? We don't want rumpbake to spit out anything
except the binary. All we need is an offline "here's a directory, turn
it and its subdirectories into a component" tool/documented
command/whatever, no quirky "add secret files" semantics.
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.
I think that might be a bit optimistic, given that I spent about
three days just thinking and drafting this email :-/
Based on months of thinking about this issue, I no longer think it's
optimistic. The only thing that needs to happen is to start from the
bottom (e.g. defining cfg.json format) and forget about starting from
the middle -- it *was* a smart idea.
I'll end with a quote from my science mentor, Dr. Cranium:
"it is very important to stay flexible. sometimes the experiment may
give a different result from the one predicted by the hypothesis. since
real scientists don't like to make mistakes, we always write the
hypothesis in pencil."
