On 16 June 2015 at 10:36, Martin Lucina <[email protected]> wrote: > On Monday, 15.06.2015 at 18:05, Antti Kantee wrote: >> On 15/06/15 14:33, Martin Lucina wrote: > Can't or don't want to. I can think of several scenarios where I don't want > a block device: > > 1) Cloud providers (AWS, etc.) only provide block storage in gigabytes, and > each cloud provider has their own specific mechanism for provisioning such > storage. I don't expect the former to change any time soon, and support for > the latter in rumprun is going to take some time to materialise, if at all > (worth a separate discussion about the scope of rumprun, not here). > > Therefore, if I want to run a minimal and small[*] service as a rumprun > unikernel in the cloud *today*, and that service does not need any > persistent data, why should I bother with an (external) block device at all? > > 2) Expanding on Andrew's point about "ease of deployment" from a later > reply in this thread, the ability to have a single self-contained > image containing all code, data and configuration needed to run a service > is extremely appealing to many people. For example, the Mirage folks use a > deployment workflow based on exactly this [3]. > > Another important usability point for such self-contained kernels is that > they are extremely easy to migrate from "development and testing on local > laptop with KVM" to "deployment on $CLOUD". In fact, the only thing missing > for this to work right now is network device autoconfiguration by default > (separate discussion again). > > 3) For my own deployments, I want to use Xen as provided and supported by > the Linux distribution I run on my dom0, and I'd like my unikernels to boot > fast. Currently that rules out using image files for block devices as > booting a unikernel using such a block device takes seconds due to spawning > a new qemu instance (which I don't want either, even if it was fast!). I'm > sure this will get fixed eventually, but I can't wait months until such > fixes trickle down to production deployments of Xen. I can work around this > today by using LVM volumes, however a baked-in filesystem just makes it > much easier.
Absolutely agree. Often all you need is a couple of files, eg /etc/resolv.conf or /etc/services or whatever, that programs expect, even when they do not really need them. At some point people will probably be able to use programs that dont require such stuff, but bits of libc use them. Block devices are fairly heavyweight, plus the user needs a bunch of infrastructure to create and maintain them, which is non trivial, hence the use of mkisofs in the existing nginx code. Justin
