On 30/09/15 15:20, Martin Lucina wrote:
On Wednesday, 30.09.2015 at 12:56, Antti Kantee wrote:
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.
If I understand your argument correctly it is: "We can't abstract 100% of
possible use cases in a rumprun tool, therefore the tool has no value".
That would be a pretty stupid argument. I'm sure it would have positive
value *for you* and therefore quite clearly non-zero value. The
argument is that the downsides outshadow the benefits, as explained above.
Let me repeat: "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 alternative you're proposing is: "We document the JSON spec and drop
the rumprun tool entirely, leaving developers to invoke qemu / xl
directly."
Correct?
Yes, I'm saying that it should be the level we commit to supporting in
the near term, instead of chasing pastries in high-altitude locations.
Requirements:
1) everyone can use it
2) usage does not completely suck
=> linear to document (no "if this use xyzzy tool else do that"
required), easy to understand, stable foundation
While I agree that developers are smart, IMO that doesn't imply they
should have to go read all of qemu-system-i386(1) or xl(1), xl.cfg(5), and
xl.conf(5) just to run the Nginx unikernel they built to see if this
newfangled unikernel thing is any good.
I wouldn't expect them to read all of those documents. *I* haven't read
even a single of those start-to-finish, and yet somehow I've managed to
implement rumprun for those platforms.
Why do you think people would stop reading the nginx tutorial and using
the example commands we provide in there? It's highly doubtful that
changing the commands to ones people might recognize and have prior
experience with will now scare them away to desperately reading manpages.
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?
I don't understand what you mean here. What "version of rumplaunch"?
The one I mentioned at the previous ellipsis (which wasn't quoted in
your mail). I generally use "...","..." in informal text to denote
continuation, sorry if the relationship wasn't clear.
