On Tue, 2013-11-19 at 13:46 -0500, Eric Windisch wrote: > 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.
It's certainly possible, but some of them are possible in the same way as it's possible to get a square peg into a round hole by beating the corners flat with a sledge hammer ... it works, but it's much less hassle just to use a round peg because it actually fits the job. > 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. How about this: we get the container API agreed and we use a driver model like Nova (we have to anyway since there about four different container technologies interested in this), then we see if someone wants to do a hypervisor driver emulating the features. James _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
