On Wednesday, 29.04.2015 at 06:01, Antti Kantee wrote: > On 28/04/15 23:33, Andrew Stuart wrote: > >>>You can then bake those files into an image that you present as a disk > >>>device to rumprun. > > > >I had runtime configuration in mind rather than pre-baked. Consider > >certificates and keys - I can give you a rumpkernel and if the certs can be > >copied onto the disk before launch then the kernel build process never need > >access to your certs. > > I completely agree that you shouldn't need the data files when you > build the rumprun image. > > I was suggesting you'd package your data files at launch-time. > That's essentially what Martin's run-nginx.sh does, even though it > builds the images as part of "make". You could easily make > run-nginx.sh build the images instead, and maybe we'll even add that > support to the rumprun launch tool once we gain some more > understanding of the intricacies of various use cases.
Nota bene, while using external storage as a block device is fine for now, having support in rumprun to package up a self-contained image containing both the kernel (application) and its root filesystem has some advantages: a) consistency between Xen and bare metal, at least for "minimal" unikernels with some small amount of data files b) on current (4.4) Xen setups if you use an image file (as opposed to a real dom0 block device) it requires spinning up a QEMU to provide the backend for the device. This takes time and dom0 resources. As has been mentioned in the configuration thread, this would mean implementing an initramfs-like arrangement, or possibly porting SquashFS to NetBSD.
