[openstack-dev] [nova][nova-docker] Retiring nova-docker project

James Bottomley James.Bottomley at HansenPartnership.com
Fri Jul 8 05:39:46 UTC 2016


On Thu, 2016-07-07 at 21:28 -0500, Edward Leafe wrote:
> On Jul 7, 2016, at 8:33 PM, Joshua Harlow <harlowja at fastmail.com>
> wrote:
> > 
> > That's sad, how can we fix the fact that users/deployments have
> > gone off into their own silos and may be running their own forks;
> > what went wrong (besides some of the obvious stuff that I think I
> > know about, that others probably don't) that resulted in this
> > happening?
> > 
> > Seems like something we can learn from by reflecting on this and
> > trying to find a path forward (or maybe we just accept there isn't
> > one, idk).
> 
> I think admitting that it was a conceptual mis-match from the start
> would be the first step. Containers are not VMs.

That's not a correct statement: they certainly can be orchestrated like
VMs if constructed like them: that's actually what operating system
containers are.  However, container systems are also amenable to being
constructed very differently from VMs because of the granular nature of
the virtualisations.

>  Attempts to treat them as such are always going to be poor
> compromises.

I think this reflects the persistent failure OpenStack has had in
trying to encompass the entire container space.  The problem is that
they're not monolithic, like VMs for which, whether it's ESX, KVM, Xen
or HyperV, one VM looks very like another.  The homogeneous nature of
VMs makes it natural to think containers can be pidgeonholed in the
same way ... the problem is that really, they can't.  Some container
systems absolutely can be orchestrated by nova and some can't.

Currently there is no one OpenStack system that can orchestrate the
full power of containers as presented by the raw Linux API.  I don't
think this is a particular problem because there's no industrial
consumer begging for that full power.  Right at the moment, containers
are consumed as a collection of disparate use cases and, reflecting
this, OpenStack has a variety of systems corresponding somewhat to the
consumption models.  However, being use case specific, none of them can
orchestrate an arbitrary "container" system, and, of course, any new
use case that arises likely doesn't fit with any of the current models.
 Reality is being messy again, I'm afraid.

> Containers have an important place in OpenStack; it's just not in
> Nova.

Following this theory, the next move would be trying to remove the lxc
and vz container drivers from nova?  I really don't think that's a good
idea because the fit is quite useful for a significant set of use
cases.

James


> 
> -- Ed Leafe
> 
> 
> 
> 
> 
> _____________________________________________________________________
> _____
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160707/37126c7d/attachment.pgp>


More information about the OpenStack-dev mailing list