On Tue, Nov 19, 2013 at 1:02 PM, James Bottomley <james.bottom...@hansenpartnership.com> wrote: > On Mon, 2013-11-18 at 14:28 -0800, Stuart Fox wrote: >> Hey all >> >> 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. > > I can take a stab at this: Firstly, a container is *not* a hypervisor. > Hypervisor based virtualisation is done at the hardware level (so with > hypervisors you boot a second kernel on top of the virtual hardware), > container based virtualisation is done at the OS (kernel) level (so all > containers share the same kernel ... and sometimes even huge chunks of > the OS). With recent advances in the Linux Kernel, we can make a > container behave like a hypervisor (full OS/IaaS virtualisation), but > quite a bit of the utility of containers is that they can do much more > than hypervisors, so they shouldn't be constrained by hypervisor APIs > (which are effectively virtual hardware APIs). > > It is possible to extend the Nova APIs to control containers more fully, > but there was resistance do doing this on the grounds that it's > expanding the scope of Nova, hence the new project.
It might be worth noting that it was also brought up that hypervisor-based virtualization can offer a number of features that bridge some of these gaps, but are not supported in, nor may ever be supported in Nova. For example, Daniel brings up an interesting point with the libvirt-sandbox feature. This is one of those features that bridges some of the gaps. There are also solutions, however brittle, for introspection that work on hypervisor-driven VMs. It is not clear what the scope or desire for these features might be, how they might be sufficiently abstracted between hypervisors and guest OSes, nor how these would fit into any of the existing or planned compute API buckets. Having a separate service for managing containers draws a thick line in the sand that will somewhat stiffen innovation around hypervisor-based virtualization. That isn't necessarily a bad thing, it will help maintain stability in the project. However, the choice and the implications shouldn't be ignored. -- Regards, Eric Windisch _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
