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". 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? 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. > >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"? > >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. Quoting my original email about baked-in rootfs support: "rumpbake now accepts multiple '-R PATH' options. Each -R option adds the contents of PATH to the root filesystem for the unikernel we are baking." I don't see any quirky "add secret files" semantics there. The only difference (which I'm fine with) is that it should be a separate tool that spits out a "file system data" component, which you can link in to your unikernel with rumpbake. I thought your main complaint was about my implementation, which used Justin's libuntar and unpacked it into the rootfs, hence my reference to a linkable component containing a MFS filesystem. -mato
