> > Hmm, are you using the "raw" qemu command to avoid having to download the > rumprun launcher?
Yep > The config format is currently a non-public API, so using the rumprun > launcher is preferred. The config syntax will change once we get the > config file format finalized. Would it be possible to bundle the rumprun > tool using dtuf, or does dtuf not permit multiple files? A dtuf target is a name for a list of blobs. Each blob has a size and a digest but not separately a name. I'd much rather distribute a config than rumprun - asking users to execute an arbitrary program is much less safe than giving a unikernel + config to qemu. > The "dtuf pull-target" spell sort of hints that it doesn't, at least > unless you distribute a tarball and pipe to tar -zxf. > I can think of some options: - tarball (as you suggested) - Have a convention which says the first blob is always the Rumprun binary and then second one is the default config - Publish the default config separately, appending '.cfg' (or whatever) - e.g. 0.7.8-x86_64-rumprun-netbsd-hw_generic.cfg - Invent a manifest format and publish that in the repo (e.g. with the target name 'MANIFEST'). The manifest would describe the image and how to run it. Docker takes this approach for containers. However when I asked on https://github.com/docker/distribution/pull/1068 whether it would be better to do something more opaque, there was some support. I don't really want to go down the route they took. In general, I don't really fancy building a manifest spec into dtuf - at the moment it knows nothing about Unikernels and I'd prefer it to stay that way. > > Thinking ahead, I guess in the future one could distribute an example > config, and then the qemu spell would be: qemu ... -initrd rumprun.cfg > That would be super cool. We should definitely keep the tooling (and config) separate from distribution.
