To add a bit of context:<p>- The OpenStack project makes a major release every six months. The feature freeze for the next release (codename: Havana, scheduled to be GA mid-October) was 00:00 UTC this morning. As this commit has been approved prior to the cutoff, that means that (barring any serious problems it may unintentionally cause, which is unlikely as hypervisor drivers are isolated from one another) it will be included in the Havana release.<p>- It's probably more accurate to say that a new <i>hypervisor driver</i> has been added, rather than a new <i>hypervisor</i>. OpenStack is an orchestration layer that is used for allocating resources to users/projects (more in an excellent comment here: <a href="https://news.ycombinator.com/item?id=6330947" rel="nofollow">https://news.ycombinator.com/item?id=6330947</a>) and has support for a number of hypervisor drivers, including the usual suspects (VMware, XenServer, and KVM) as well as non-hypervisors (baremetal and others). Docker, and the container technology upon which it is based, is not traditionally considered hypervisor virtualization.<p>- OpenStack has been evolving as a sort of "Linux of the Cloud", and as such, a number of "distributions" (for lack of a better / easier-to-understand term) have cropped up to make installing, setting up, and running an OpenStack-based cloud easier/manageable/supportable. Some distributions take a more free-form approach with respect to what they include. Others provide a single vertical stack which they support (e.g. KVM-only) and using a different hypervisor driver would either be unsupported or in some cases (and for reasons I won't get into) impossible.<p>- Running Docker on top of OpenStack / within OpenStack has been possible for as long as both platforms have co-existed, as OpenStack has always been capable of running Linux VMs and Docker has always been capable of running within Linux VMs. What this patch allows is for OpenStack to orchestrate Docker container provisioning, and take advantage of the not only the orchestration capabilities of OpenStack but also the client/API/library support.<p>I have no connection to the Docker project but I do applaud the Docker OpenStack team as getting a new hypervisor driver into OpenStack is no small feat!<p>EDIT: typo
Does this mean I can run OpenStack "on" OpenStack or other public clouds to do, for example, virtualization of storage and compute resources across VMs provided by Amazon, RackSpace, Microsoft, and others?<p>Of course there is redundancy in this approach, but what is the point of abstraction if I cannot layer abstraction on abstraction?<p>Edit: I ask because OpenStack has perpetually seem like a project just barely beyond my needs. I love the idea (or perhaps mistaken idea, I have never implemented it) that it would abstract roles from the nodes they ran on, a way of skirting more serious configuration management a la Chef or Puppet, and providing other, orthogonal, capabilities. For example, I would like to not have to be dependent on the storage implementations of the public cloud I run on. There is fragility in implementing a project on Azure when it becomes tied to Azure's APIs for blob storage.
More info here: <a href="https://github.com/dotcloud/openstack-docker/blob/master/docs/nova_blueprint.md" rel="nofollow">https://github.com/dotcloud/openstack-docker/blob/master/doc...</a><p>Also, it's available in devstack by adding "VIRT_DRIVER=docker" in your localrc.
This is always a good news, but honestly, I am little dissappointed this is yet another Linux based hypervisor, while OpenStack supports already few, not mentioning it supports LXC itself. What about BSD derived ones, like Jails or rising BHyve? I would love to see these supported!