On Thursday, 11.02.2016 at 16:07, Martin Lucina wrote: > My intent with unikernel-runner is to use it as a platform to experiment > with: > > 1. Improving Docker/unikernel integration.(e.g. native support for L2 > connectivity so that CAP_NET_ADMIN is not required) > 2. Use it as a "higher level stack" client for the rumprun configuration > specification, so that I can validate and test that work. > 3. Supporting other unikernel projects, either by adding specific support > to unikernel-runner or getting other projects on board with using the > configuration spec. > 4. Distributing "ready-to-run" binary unikernels using Docker Hub. This > ties in with David Halls' work[4], and completes the stack with > Docker+KVM providing the "run" part.
To elaborate some more on these points, especially 2., 3. and 4.: Rumprun (and Mirage, and HalVM, and ...) solve the "how to build your app as a unikernel" step. Once you have a unikernel, how do you distribute and deploy it? As Dave has demonstrated with his work on distributing Node.js unikernels, using a Docker registry is a good solution for distribution. What I'd like to experiment with is: What's involved in distributing a ready-to-run unikernel as a Docker registry image? What goes into that image? How does the launching stack (not necessarily Docker engine!) interact with configuration supplied by the image, if any? Is it possible to distribute images (and configuration specifications) that are independent of the launching stack (i.e. without the /runtime in it)? Can we make the configuration specification portable across different unikernel projects? To address Antti's point about docker-unikernel-runner being "a Docker-specific way to run unikernels": Yes, it happens to use Docker components both for distribution (registry) and run (engine) because both pieces are there and work today.
