+1 for "container-in-vm" On Fri, Nov 6, 2015 at 10:48 PM, Antoni Segura Puimedon < [email protected]> wrote:
> > > On Fri, Nov 6, 2015 at 1:20 PM, Baohua Yang <[email protected]> wrote: > >> It does cause confusing by calling container-inside-vm as nested >> container. >> >> The "nested" term in container area usually means >> container-inside-container. >> > > I try to always put it as VM-nested container. But I probably slipped in > some mentions. > > >> we may refer this (container-inside-vm) explicitly as vm-holding >> container. >> > > container-in-vm? > > >> >> On Fri, Nov 6, 2015 at 12:13 PM, Vikas Choudhary < >> [email protected]> wrote: >> >>> @Gal, I was asking about "container in nova vm" case. >>> Not sure if you were referring to this case as nested containers case. I >>> guess nested containers case would be "containers inside containers" and >>> this could be hosted on nova vm and nova bm node. Is my understanding >>> correct? >>> >>> Thanks Gal and Toni, for now i got answer to my query related to >>> "container in vm" case. >>> >>> -Vikas >>> >>> On Thu, Nov 5, 2015 at 6:00 PM, Gal Sagie <[email protected]> wrote: >>> >>>> The current OVS binding proposals are not for nested containers. >>>> I am not sure if you are asking about that case or about the nested >>>> containers inside a VM case. >>>> >>>> For the nested containers, we will use Neutron solutions that support >>>> this kind of configuration, for example >>>> if you look at OVN you can define "parent" and "sub" ports, so OVN >>>> knows to perform the logical pipeline in the compute host >>>> and only perform VLAN tagging inside the VM (as Toni mentioned) >>>> >>>> If you need more clarification you can catch me on IRC as well and we >>>> can talk. >>>> >>>> On Thu, Nov 5, 2015 at 8:03 AM, Vikas Choudhary < >>>> [email protected]> wrote: >>>> >>>>> Hi All, >>>>> >>>>> I would appreciate inputs on following queries: >>>>> 1. Are we assuming nova bm nodes to be docker host for now? >>>>> >>>>> If Not: >>>>> - Assuming nova vm as docker host and ovs as networking >>>>> plugin: >>>>> This line is from the etherpad[1], "Eachdriver would have >>>>> an executable that receives the name of the veth pair that has to be bound >>>>> to the overlay" . >>>>> Query 1: As per current ovs binding proposals by >>>>> Feisky[2] and Diga[3], vif seems to be binding with br-int on vm. I am >>>>> unable to understand how overlay will work. AFAICT , neutron will >>>>> configure >>>>> br-tun of compute machines ovs only. How overlay(br-tun) configuration >>>>> will >>>>> happen inside vm ? >>>>> >>>>> Query 2: Are we having double encapsulation(both at vm >>>>> and compute)? Is not it possible to bind vif into compute host br-int? >>>>> >>>>> Query3: I did not see subnet tags for network plugin >>>>> being passed in any of the binding patches[2][3][4]. Dont we need that? >>>>> >>>>> >>>>> [1] https://etherpad.openstack.org/p/Kuryr_vif_binding_unbinding >>>>> [2] https://review.openstack.org/#/c/241558/ >>>>> [3] https://review.openstack.org/#/c/232948/1 >>>>> [4] https://review.openstack.org/#/c/227972/ >>>>> >>>>> >>>>> -Vikas Choudhary >>>>> >>>>> >>>>> __________________________________________________________________________ >>>>> OpenStack Development Mailing List (not for usage questions) >>>>> Unsubscribe: >>>>> [email protected]?subject:unsubscribe >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> Best Regards , >>>> >>>> The G. >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> [email protected]?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> >> -- >> Best wishes! >> Baohua >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
