Open Stack

On Tue, Nov 19, 2013 at 10:57:51AM +0100, Thierry Carrez wrote:
> Russell Bryant wrote:
> > My view of the outcome of the session was not "it *will* be a new
> > service".  Instead, it was, "we *think* it should be a new service, but
> > let's do some more investigation to decide for sure".
> > 
> > The action item from the session was to go off and come up with a
> > proposal for what a new service would look like.  In particular, we
> > needed a proposal for what the API would look like.  With that in hand,
> > we need to come back and ask the question again of whether a new service
> > is the right answer.
> 
> +1
> 
> I can see how a separate service can be a good way to avoid making Nova
> support container-specific use cases and make it even bigger than it is.
> However if you end up duplicating most of the code, I'm not sure there
> would be any net gain.
> 
> I'm not talking about the base service infrastructure and the scheduler
> (which are well-known duplication already) but more around specific nova
> features (metadata/config drive, networking, image handling, etc.) that
> would apply to VMs and containers alike.
> 
> So it would be great to come out of this first round of analysis with a
> plan detailing how different (and how similar) from nova that new
> service would be, and how much code duplication is to be expected.

Yep, I'm far from convinced that having a separate service for
containers is going to be a net gain for the project as a whole.
It seems to me that we're likely to have an API and codebase that
is 95% the same in both cases here, with most differences just
being about the way things are initially booted/provisioned.

While containers certainly have some unique attributes, I believe
the level of differentiation is overblown. I also think the difference
is not about  containers vs VMs, but rather about OS virtualization vs
application virtualization.

It is entirely practical to do application virtualization using
either containers or VMs, as demonstrated by libvirt-sandbox which
can run individual app processes inside KVM without needing a full
OS intsall for it. There are notable security advantages to using
KVM for application virtualization since it avoids the shared kernel
single point of failure/compromise.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|