Open Stack

On Wed, Dec 7, 2016 at 8:47 AM, Vasyl Saienko <vsaienko at 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).


>
> Reference:
>
> [0] https://review.openstack.org/#/c/277853/
> [1] https://review.openstack.org/#/c/277853/10/specs/approved/
> VLAN-aware-baremetal-instances.rst at 35
>
> On Wed, Dec 7, 2016 at 6:14 PM, Kevin Benton <kevin at 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. <armamig at gmail.com> wrote:
>>
>>>
>>>
>>> On 7 December 2016 at 04:02, Vasyl Saienko <vsaienko at 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 at 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. <armamig at gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 6 December 2016 at 08:49, Vasyl Saienko <vsaienko at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161207/464c58be/attachment.html>