On 13 July 2016 at 16:51, Kevin Benton <[email protected]> wrote: > Sub ports are just regular ports from a logical model perspective, right? > If so, there should be no problem attaching the port to a shared network or > RBAC granted network. >
True, but I don't believe it until I test it :) On Jul 13, 2016 7:15 PM, "Armando M." <[email protected]> wrote: > >> >> >> On 13 July 2016 at 15:32, Cathy Zhang <[email protected]> wrote: >> >>> Hi Everyone, >>> >>> We have been discussing on multi-tenant VNF for service chain on the OVN >>> mailing alias. >>> We are thinking about leveraging the vlan-aware-VM for supporting this. >>> >>> AFAIK, with current nova, we cannot create a multi-tenant VNF. >>> Currently, nova checks whether the neutron port belongs to the same >>> tenant as the VM itself. >>> You attach a network interface (neutron port) to a VM using nova >>> interface-attach, if the port and the VM are in different tenants, an error >>> is given. >>> >>> With the introduction of the trunk-port/sub-port feature of Neutron, the >>> sub-ports of a VM are allowed to associate with different networks. But it >>> seems these networks need to all belong to the same tenant if we read the >>> vlan-aware-vm spec correctly ( >>> http://specs.openstack.org/openstack/neutron-specs/specs/newton/vlan-aware-vms.html >>> ). >>> >>> Is our understanding correct? Does it work properly if these networks >>> belong to different tenants? >>> >> >> At the moment this area is still WIP, but we're focusing on the single >> tenant use case. RBAC may help us down the road to address what you need, >> but it's premature to speculate on how the implementation looks like. >> >> Cheers, >> Armando >> >> >>> >>> Thanks, >>> Cathy >>> >>> -----Original Message----- >>> From: dev [mailto:[email protected]] On Behalf Of Farhad >>> Sunavala >>> Sent: Tuesday, July 12, 2016 7:59 PM >>> To: [email protected] >>> Subject: Re: [ovs-dev] SFC-Summary: MultiTenant >>> >>> >I was thinking this could be handled with child / sub-ports. We do >>> >this today for containers in VMs. We can have a single VIF for a VM >>> >that is connected to multiple networks that are owned by separate >>> >tenants. Some sort of encapsulation (VLAN ID, MPLS header, whatever) >>> >would be used to differentiate the traffic for each networking in/out >>> >of that VIF. I had started adding the ability to use MPLS for this in >>> >my prototype for this reason, as that was what networking-sfc had >>> defined. >>> I have a quick question on the above. (multi-tenancy).Yes, I know the >>> containers can be in different networks of the same tenant.How does it work >>> when the containers are in different tenants ? >>> Below is the latest spec for vlan-aware-vms >>> https://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html >>> >>> The trick is to create neutron ports (for the subports) and then link >>> them to the trunk port using neutron trunk-subport-add TRUNK \ >>> PORT[,SEGMENTATION-TYPE,SEGMENTATION-ID] \ [PORT,...] >>> >>> In the above command all the neutron ports (trunk ports and subports) >>> must be in the same tenant.As far as I know, a tenant will not see neutron >>> ports from another tenant. Or will this command allow neutron ports from >>> different tenants to be attached ? >>> E.g. VM "X" consists of containers C1 in Tenant 1 with portID = C10000 >>> (network dn1)container C2 in Tenant 2 with portID = C20000 (network dn2)The >>> trunk port of VM "X" is in tenant 100 with portID = T10000 (network dt) The >>> above command will be neutron trunk-subport-add T10000 \ A vlan 10000 \ >>> B vlan 20000 Is my understanding correct? thanks,Farhad. >>> _______________________________________________ >>> dev mailing list >>> [email protected] >>> http://openvswitch.org/mailman/listinfo/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 >> >> > __________________________________________________________________________ > 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
