On Mon, May 11, 2015 at 02:57:08PM +0100, John Garbutt wrote: > On 9 May 2015 at 17:55, Adrian Otto <adrian.o...@rackspace.com> wrote: > > On the subject of extending the Nova API to accommodate special use cases > > of containers that are beyond the scope of the Nova API, I think we should > > resist that, and focus those container-specific efforts in Magnum. > > +1 > The API is my biggest worry here. > > > I will also mention that it’s natural to be allergic to the idea of nested > > virtualization. We all know that creating multiple levels of hardware > > virtualization leads to bad performance outcomes. However, "nested > > containers" do not carry that same drawback, because the actual overhead of > > a Linux cgroup and Kernel Namespeaces are much lighter than a hardware > > virtualization. There are cases where having a container-in-container setup > > gives compelling benefits. That’s why I’ll argue vigorously for both Nova > > and Magnum to be able to produce container instances both at the machine > > level, and allow Magnum to produce "nested containers” to produce better > > workload consolidation density. in a setup with no hypervisors at all. > > +1 > Agreed nested containers are a thing. > Its a great reason to keep our LXC driver. > > > To sum up, I strongly support merging in nova-docker, with the caveat that > > it operates within the existing Nova API (with few minor exceptions). For > > features that require API features that are truly container specific, we > > should land those in Magnum, and keep the Nova API scoped to operations > > that are appropriate for “all" instance types. > > I am keen we set the right expectations here. > If you want to treat docker containers like VMs, thats OK. > > I guess a remaining concern is the driver dropping into diss-repair if > most folks end up using Magnum when they want to use docker.
Yep, I'm personally fine with Docker being merged into Nova from a technical and design POV. My only two requirements are social/community ones - Do we have a team of people willing and able to commit to maintaining it in Nova - ie we don't just want it to bitrot and have nova cores left to pick up the pieces whenever it breaks. - Are there enough people who are actally interested in using Docker-in-Nova, that it is worth the overhead for that team of maintainers. We don't want to decide to support something that hardly anyone ends up using, because that could divert resources away that could usefully be put on Docker-in-Magnum and get a better return on investment for users. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev