So, the story so far:
1) the rumprun launch tool was a good idea to try out, but since it
abstracts too much to be able to deal with many real-world situations,
we need another solution which does not prevent users from doing what
they want
2) removing the convenience tool raised concerns about the local
iteration that developers do
3) keeping a developer convenience tool for special cases raised issues
about the simplicity of documentation
4) passing the guest json config at launch-time always requires some
special tricks, e.g. running it through sed for qemu or the xenstore
magic incantations with xl. a tool for just those magic bits was
attempted, but it wasn't seen as clean enough to warrant continued
concerns about "2".
Requirement:
The configuration mechanism should provide a foundation which allows all
cases to be handled, even if the mechanism does not inherently support
all cases.
So, the next experiment:
Make rumprun-bake include a config in the binary. It's dead simple,
work always, allows for developer iteration with almost the same speed
as the old rumprun launcher, never hides anything from the user, and
(very important) allows testing without having set up any additional
infrastructure.
Configs are given with 0 or more [-b bootspec] params, e.g.:
rumprun-bake -b net.json -b run.json hw_virtio nc.bin nc
where net.json:
"net" : {
"if" : "vioif0",
"type" : "inet",
"method": "dhcp",
}
and run.json:
"cmdline" : "netcat -l -p 3000"
And then you just run it with e.g. qemu:
qemu-system-x86_64 -net user,hostfwd=tcp::3000-:3000 -net
nic,model=virtio -kernel nc.bin
(yea i was testing the DAD fix for issue #56 earlier today)
net.json can be mostly copypasted (or we can even provide some template
for it), run.json is obvious, qemu command line is either known or can
be copypasted from a tutorial. So, in other words, easy-peasy.
Furthermore, the initial guest side config works the same regardless of
if you run the ELF image directly, subsequently stuff it into an ISO, or
whatever, so there's simplicity and lack of code there too.
The only thing left is power users. If you want to run 1000 instances,
do you need 1000 binaries? No, for that we can/should add a "read more
config from location X" directive. X can be for example the command
line params (with all the magic they entail), or a networked data
storage server (the initial config needs to provide networking in that
case). Obviously, X needs to be something that your target environment
can handle, but that's not our problem, and the whole further config is
not the issue here and now.
So, in other words, the purpose of the -b parameter to suck so little
that anyone doing local iteration will not be put off immediately, but
also not promise to provide world peace, just promise not to prevent it.
For those who want to try out the usability of the approach, I pushed
the code (which literally took way less time to write than this email)
onto the pooka-bakespec branch (no, I didn't adjust the test launch
mechanism, so the automated tests are broken on the branch).
Thoughts?
