OpenStack adds new hypervisor to support Docker containers
review.openstack.org
review.openstack.org
- 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.
- It's probably more accurate to say that a new hypervisor driver has been added, rather than a new hypervisor. OpenStack is an orchestration layer that is used for allocating resources to users/projects (more in an excellent comment here: https://news.ycombinator.com/item?id=6330947) 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.
- 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.
- 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.
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!
EDIT: typo
Docker author here. The credit goes to Sam Alba (shad42 on hn) who lead this integration beginning to end - in addition to his day job of director of engineering at dotCloud :)
Of course there is redundancy in this approach, but what is the point of abstraction if I cannot layer abstraction on abstraction?
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.
If you try to do this yourself, bear in mind that getting the core services replicated across multiple public cloud servers in order to tolerate failures could be challenging, and you'd need to set up a network spanning all the clouds you wanted to abstract away using a VPN or similar so that your mysql and rabbit servers aren't facing the public internet.
There is a team at HP doing Openstack on Openstack, though with very different goals. https://wiki.openstack.org/wiki/TripleO
Also, it's available in devstack by adding "VIRT_DRIVER=docker" in your localrc.