Open Stack

> Not having been at the summit (maybe the next one), could somebody
> give a really short explanation as to why it needs to be a separate
> service? It sounds like it should fit within the Nova area. It is,
> after all, just another hypervisor type, or so it seems.

But it's not just another hypervisor. If all you want from your
containers is lightweight VMs, then nova is a reasonable place to put
that (and it's there right now). If, however, you want to expose the
complex and flexible attributes of a container, such as being able to
overlap filesystems, have fine-grained control over what is shared with
the host OS, look at the processes within a container, etc, then nova
ends up needing quite a bit of change to support that.

I think the overwhelming majority of folks in the room, after discussing
it, agreed that Nova is infrastructure and containers is more of a
platform thing. Making it a separate service lets us define a mechanism
to manage these that makes much more sense than treating them like VMs.
Using Nova to deploy VMs that run this service is the right approach,
IMHO. Clayton put it very well, I think:

  If the thing you want to deploy has a kernel, then you need Nova. If
  your thing runs on a kernel, you want $new_service_name.

I agree.

Note that this is just another service under the compute project (or
program, or whatever the correct terminology is this week). So while
distinct from Nova in terms of code, development should be tightly
integrated until (and if at some point) it doesn't make sense.

--Dan