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. Thanks, John __________________________________________________________________________ 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
