On Wednesday, 20.05.2015 at 11:49, Antti Kantee wrote:
> On 20/05/15 08:51, Martin Lucina wrote:
> >A bootable Xen PV ISO will probably require mucking with
> >pygrub/pvgrub/whatever it's called, which is a bunch of work and another
> >dependency for not a whole lot of gain.
> >
> >What I would do as a first step for AWS is ignore the problem of block
> >devices for now and figure out if we can create an AKI (Amazon Kernel
> >Image) from a rumprun unikernel, and try and boot that.
> >
> >Once that works the next step has been discussed here before, baking a root
> >filesystem into the unikernel image, in the style of Linux initrd.
> >
> >Andrew: If you have some time, could you try and make the first step work?
> >It should be fairly straightforward assuming there's a tool that turns an
> >ELF kernel image into the AKI.
> 
> Thank you for sharing that knowledge.
> 
> >Regarding the Xenstore-based rumprun configuration, I'm not particularly
> >attached to it. I have some vague ideas about it being useful in scenarios
> >where multiple unikernels are cooperating on a single dom0 but that can
> >probably be (re-)done in other ways when it comes up.
> 
> Unless your vague ideas are still at a stage where they're too
> difficult to put into writing, can you be more specific on what that
> cooperation would look like?  Maybe it will "just work" if we go in
> the right direction now instead of ending up having to fix it later.

<handwaving>

Xenstore provides a shared key-value store and simple publish-subscribe
("watch") mechanism shared by all domUs running on the dom0.

So, it's relatively easy to implement things like management and service
discovery. Examples:

- A more rumprun-friendly wrapper to xl which can discover running
  unikernels through Xenstore and manage them.

- Have a service on the dom0 (or, ideally, in another unikernel) watch for
  unikernels starting up and shutting down and manage DNS entries /
  firewall rules / port mappings for them.

Granted, other projects already exist that do this outside of Xen (eg. etcd
for CoreOS, consul.io that Justin mentioned). However, I'd prefer that we
re-use existing infrastructure rather than add more dependencies. Also,
Xenstore is a "trusted" path and unlike the other projects mentioned does
not depend on you setting up a TCP management network, dealing with
authentication (assuming you operate the dom0), etc.

Tangentially related: While replying to Andrew's success with EC2: If
possible I'd like to do without PVGRUB altogether. That would mean booting
unikernels directly on AWS, which again runs into the question of how to
pass configuration information to them. Xenstore is an obvious choice give
that it's already there. Of course this would require support from AWS, and
I'd need to discuss with AWS engineers whether or not it makes sense for
them. Hopefully at the Xen Summit in Seattle in August.

</handwaving>

Reply via email to