On Wed, Dec 7, 2016 at 7:12 PM, Kevin Benton <ke...@benton.pub> wrote:
> > > On Wed, Dec 7, 2016 at 8:47 AM, Vasyl Saienko <vsaie...@mirantis.com> > wrote: > >> @Armando: IMO the spec [0] is not about enablement of Trunks and >> baremetal. This spec is rather about trying to make user request with any >> network configuration (number of requested NICs) to be able successfully >> deployed on ANY ironic node (even when number of hardware interfaces is >> less than number of requested attached networks to instance) by implicitly >> creating neutron trunks on the fly. >> >> I have a concerns about it and left a comment [1]. The guaranteed number >> of NICs on hardware server should be available to user via nova flavor >> information. User should decide if he needs a trunk or not only by his own, >> as his image may even not support trunking. I suggest that creating trunks >> implicitly (w/o user knowledge) shouldn't happen. >> >> Current trunks implementation in Neutron will work just fine with >> baremetal case with one small addition: >> >> 1. segmentation_type and segmentation_id should not be API mandatory >> fields at least for the case when provider segmentation is VLAN. >> >> 2. User still should know what segmentation_id was picked to configure it >> on Instance side. (Not sure if it is done automatically via network >> metadata at the moment.). So it should be inherited from network >> provider:segmentation_id and visible to the user. >> >> >> @Kevin: Having VLAN mapping support on the switch will not solve problem >> described in scenario 3 when multiple users pick the same segmentation_id >> for different networks and their instances were spawned to baremetal nodes >> on the same switch. >> >> I don’t see other option than to control uniqueness of segmentation_id on >> Neutron side for baremetal case. >> > > Well unless there is a limitation in the switch hardware, VLAN mapping is > scoped to each individual port so users can pick the same local > segmentation_id. The point of the feature on switches is for when you have > customers that specify their own VLANs and you need to map them to service > provider VLANs (i.e. what is happening here). > It work only when whole switch is aimed by single customer, it will not work when several customers sharing the same switch. > > >> >> Reference: >> >> [0] https://review.openstack.org/#/c/277853/ >> [1] https://review.openstack.org/#/c/277853/10/specs/approved/VL >> AN-aware-baremetal-instances.rst@35 >> >> On Wed, Dec 7, 2016 at 6:14 PM, Kevin Benton <ke...@benton.pub> wrote: >> >>> Just to be clear, in this case the switches don't support VLAN >>> translation (e.g. [1])? Because that also solves the problem you are >>> running into. This is the preferable path for bare metal because it avoids >>> exposing provider details to users and doesn't tie you to VLANs on the >>> backend. >>> >>> 1. http://ipcisco.com/vlan-mapping-vlan-translation-%E2%80%93-part-2/ >>> >>> On Wed, Dec 7, 2016 at 7:49 AM, Armando M. <arma...@gmail.com> wrote: >>> >>>> >>>> >>>> On 7 December 2016 at 04:02, Vasyl Saienko <vsaie...@mirantis.com> >>>> wrote: >>>> >>>>> Armando, Kevin, >>>>> >>>>> Thanks for your comments. >>>>> >>>>> To be more clear we are trying to use neutron trunks implementation >>>>> with baremetal servers (Ironic). Baremetal servers are plugged to Tor (Top >>>>> of the Rack) switch. User images are spawned directly onto hardware. >>>>> >>>> Ironic uses Neutron ML2 drivers to plug baremetal servers to Neutron >>>>> networks (it looks like changing vlan on the port to segmentation_id from >>>>> Neutron network, scenario 1 in the attachment). Ironic works with VLAN >>>>> segmentation only for now, but some vendors ML2 like arista allows to use >>>>> VXLAN (in this case VXLAN to VLAN mapping is created on the switch.). >>>>> Different users may have baremetal servers connected to the same ToR >>>>> switch. >>>>> >>>>> By trying to apply current neutron trunking model leads to the >>>>> following errors: >>>>> >>>>> *Scenario 2: single user scenario, create VMs with trunk and non-trunk >>>>> ports.* >>>>> >>>>> - User create two networks: >>>>> net-1: (provider:segmentation_id: 100) >>>>> net-2: (provider:segmentation_id: 101) >>>>> >>>>> - User create 1 trunk port >>>>> port0 - parent port in net-1 >>>>> port1 - subport in net-2 and define user segmentation_id: 300 >>>>> >>>>> - User boot VMs: >>>>> BM1: with trunk (connected to ToR Fa0/1) >>>>> BM4: in net-2 (connected to ToR Fa0/4) >>>>> >>>>> - VLAN on the switch are configured as follow: >>>>> Fa0/1 - trunk, native 100, allowed vlan 300 >>>>> Fa0/4 - access vlan 101 >>>>> >>>>> *Problem:* BM1 has no access BM4 on net-2 >>>>> >>>>> >>>>> *Scenario 3: multiple user scenario, create VMs with trunk.* >>>>> >>>>> - User1 create two networks: >>>>> net-1: (provider:segmentation_id: 100) >>>>> net-2: (provider:segmentation_id: 101) >>>>> >>>>> - User2 create two networks: >>>>> net-3: (provider:segmentation_id: 200) >>>>> net-4: (provider:segmentation_id: 201) >>>>> >>>>> - User1 create 1 trunk port >>>>> port0 - parent port in net-1 >>>>> port1 - subport in net-2 and define user segmentation_id: 300 >>>>> >>>>> - User2 create 1 trunk port >>>>> port0 - parent port in net-3 >>>>> port1 - subport in net-4 and define user segmentation_id: 300 >>>>> >>>>> - User1 boot VM: >>>>> BM1: with trunk (connected to ToR Fa0/1) >>>>> >>>>> - User2 boot VM: >>>>> BM4: with trunk (connected to ToR Fa0/4) >>>>> >>>>> - VLAN on the switch are configured as follow: >>>>> Fa0/1 - trunk, native 100, allowed vlan 300 >>>>> Fa0/4 - trunk, native 200, allowed vlan 300 >>>>> >>>>> *Problem:* User1 BM1 has access to User2 BM4 on net-2, Conflict in >>>>> VLAN mapping provider vlan 101 should be mapped to user vlan 300, and >>>>> provider vlan 201 should be also mapped to vlan 300 >>>>> >>>>> >>>>> Making segmentation_id on trunk subport optional and inheriting it >>>>> from port network segmentation_id solves such problems. >>>>> According to original spec both segmentation_type and segmentation_id >>>>> are optional [0]. >>>>> >>>>> Does Neutron/Nova place information about user's VLAN onto instance >>>>> via network metadata? >>>>> >>>>> Reference: >>>>> [0] https://review.openstack.org/#/c/308521/1/specs/newton/v >>>>> lan-aware-vms.rst@118 >>>>> >>>> >>>> Ah, I was actually going to add the following: >>>> >>>> Whether segmentation type and segmentation ID are mandatory or not >>>> depends on the driver in charge of the trunk. This is because for use cases >>>> like Ironic, as you wonder, these details may be inferred by the underlying >>>> network, as you point out. >>>> >>>> However, we have not tackled the Ironic use case just yet, for the main >>>> reason that ironic spec [1] is still WIP. So as far as newton is concerned, >>>> Ironic is not on the list of supported use cases for vlan-aware-vms, yet >>>> [2]. The reason why we have not tackled it yet is that there's the >>>> 'nuisance' in that a specific driver is known to the trunk plugin only at >>>> the time a parent port is bound and we hadn't come up with a clean and >>>> elegant way to developer a validator that took into account of it. I'll >>>> file a bug report to make sure this won't fall through the cracks. It'll be >>>> tagged with 'trunk'. >>>> >>>> [1] https://review.openstack.org/#/c/277853/ >>>> [2] https://github.com/openstack/neutron/blob/master/neutron >>>> /services/trunk/rules.py#L215 >>>> >>>> Cheers, >>>> Armando >>>> >>>> >>>>> >>>>> Thanks in advance, >>>>> Vasyl Saienko >>>>> >>>>> On Tue, Dec 6, 2016 at 7:08 PM, Armando M. <arma...@gmail.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 6 December 2016 at 08:49, Vasyl Saienko <vsaie...@mirantis.com> >>>>>> wrote: >>>>>> >>>>>>> Hello Neutron Community, >>>>>>> >>>>>>> >>>>>>> I've found that nice feature vlan-aware-vms was implemented in >>>>>>> Newton [0]. >>>>>>> However the usage of this feature for regular users is impossible, >>>>>>> unless I'm missing something. >>>>>>> >>>>>>> As I understood correctly it should work in the following way: >>>>>>> >>>>>>> 1. It is possible to group neutron ports to trunks. >>>>>>> 2. When trunk is created parent port should be defined: >>>>>>> Only one port can be parent. >>>>>>> segmentation of parent port is set as native or untagged vlan on >>>>>>> the trunk. >>>>>>> 3. Other ports may be added as subports to existing trunk. >>>>>>> When subport is added to trunk *segmentation_type* and >>>>>>> *segmentation_id >>>>>>> *should be specified. >>>>>>> segmentation_id of subport is set as allowed vlan on the trunk >>>>>>> >>>>>>> Non-admin user do not know anything about *segmentation_type* and >>>>>>> *segmentation_id.* >>>>>>> >>>>>> >>>>>> Segmentation type and ID are used to multiplex/demultiplex traffic >>>>>> in/out of the guest associated to a particular trunk. Aside the fact that >>>>>> the only supported type is VLAN at the moment (if ever), the IDs are user >>>>>> provided to uniquely identify the traffic coming in/out of the trunked >>>>>> networks so that it can reach the appropriate vlan interface within the >>>>>> guest. The documentation [1] is still in flight, but it clarifies this >>>>>> point. >>>>>> >>>>>> HTH >>>>>> Armando >>>>>> >>>>>> [1] https://review.openstack.org/#/c/361776 >>>>>> >>>>>> >>>>>>> So it is strange that those fields are mandatory when subport is >>>>>>> added to trunk. Furthermore they may conflict with port's network >>>>>>> segmentation_id and type. Why we can't inherit segmentation_type and >>>>>>> segmentation_id from network settings of subport? >>>>>>> >>>>>>> References: >>>>>>> [0] https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms >>>>>>> [1] https://review.openstack.org/#/c/361776/15/doc/networking-gu >>>>>>> ide/source/config-trunking.rst >>>>>>> [2] https://etherpad.openstack.org/p/trunk-api-dump-newton >>>>>>> >>>>>>> Thanks in advance, >>>>>>> Vasyl Saienko >>>>>>> >>>>>>> ____________________________________________________________ >>>>>>> ______________ >>>>>>> OpenStack Development Mailing List (not for usage questions) >>>>>>> Unsubscribe: openstack-dev-requ...@lists.op >>>>>>> enstack.org?subject:unsubscribe >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>> >>>>>>> >>>>>> >>>>>> ____________________________________________________________ >>>>>> ______________ >>>>>> OpenStack Development Mailing List (not for usage questions) >>>>>> Unsubscribe: openstack-dev-requ...@lists.op >>>>>> enstack.org?subject:unsubscribe >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>> >>>>>> >>>>> >>>>> ____________________________________________________________ >>>>> ______________ >>>>> OpenStack Development Mailing List (not for usage questions) >>>>> Unsubscribe: openstack-dev-requ...@lists.op >>>>> enstack.org?subject:unsubscribe >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>> >>>> ____________________________________________________________ >>>> ______________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: openstack-dev-requ...@lists.op >>>> enstack.org?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> ____________________________________________________________ >>> ______________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.op >>> enstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > 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 > >
__________________________________________________________________________ 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
