Folks. here's something to chew on and review during the holidays :-).
The consensus from the rumprun config/launch debate was: 1. We document the JSON configuration format used by rumprun as the public interface to configuring a rumprun unikernel. 2. We deprecate (and eventually, remove) the 'rumprun' script, possibly replacing parts of this functionality with a simpler '-launch' script for Xen and a '-build' script which builds VM images for launching on hw platforms (bare metal, KVM, EC2, ...). Given that the existing JSON format was just something that "fell out of the implementation", part (1) involved not only refactoring the specification, but also doing a complete rototill of the rumprun_config() implementation to match. This work is now feature-complete (i.e. it does everything the existing configuration implementation does) and ready for review on the 'mato-wip-rumprun-config' branch on Github: https://github.com/rumpkernel/rumprun/tree/mato-wip-rumprun-config If you're just using the 'rumprun' script to launch unikernels, nothing changes for you yet -- I have updated the script to match the new specification. So, sans new bugs, there should not be any user-visible change. However, given that the 'rumprun' script will eventually go away, and the spec will stay with us for a long time into the future, please take a look and review: https://github.com/rumpkernel/rumprun/blob/mato-wip-rumprun-config/doc/config.md Open items regarding the specification, in no particular order: 1. "rc": This is taken almost-unmodified from Antti's original proposal for running multibaked binaries. However, it still relies on the *order* of configuration entries matching up with the order of binaries baked in to the unikernel. I think it would be worth improving this to give multibaked binaries real names and select the binary to run based on "bin". This could be done by implementing a posix_spawn() and using that as the interface for spawning binaries, which would give us a public API we could point people who want to do multi-process at. 2. "env", "hostname", "net": Hopefully nothing controversial here. I plan to add a "net.dns{}" to generate resolv.conf and support for NFS mounts in some form, tentatively as "net.mount{}". 3. "blk" and "mount": This split feels logical, however the "vnd" configuration is not terribly useful in the general case without the ability to explicitly specify the order in which configuration steps are processed (i.e. being able to express what the 'rumprun iso' pseudo-rootfs code does in the config). 4. I've not changed any of the methods used to pass configuration to rumprun. However, I have only specified the multiboot module method for 'hw' and the xenstore method for 'xen'. IMO we should ditch passing JSON via the commandline entirely, which will free up the commandline for other needed things (console=, verbose=, etc.) All thoughts and critique much appreciated, looking forward to it! Martin
