Wrong segmentation ID sent to drivers when using multi-segments

Bug #1799742 reported by Rodrigo Barbieri
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Shared File Systems Service (Manila)
Invalid
Low
Unassigned

Bug Description

When using multi-segments in neutron, if we create a subnet for each segment and a share network for each subnet, when creating shares in DHSS=True mode, the driver receives the same segmentation ID for all share networks, instead of receiving the proper one for each.

Steps to reproduce:

1) Create neutron net
2) Create 3 VLAN segments (350, 360 and 370)
3) Create 3 Subnets, 1 for each segment
4) Create 3 Share Networks, 1 for each subnet
5) Create a share on each of the share networks.
6) Display the details of the share networks, they will all have the same segmentation ID (either 350, 360 or 370) instead of 1 for each

The problem is in https://github.com/openstack/manila/blob/2b40e5618f2c1039bbbbd1a3e31b72e104b5436b/manila/network/neutron/neutron_network_plugin.py#L270 where it iterates across all segments and the last one is the one that is used.

Adding a LOG.debug(str(network_info)) before invoking the driver's setup_server also shows the wrong segmentation ID is passed down to the driver.

Changed in manila:
importance: Undecided → Medium
Revision history for this message
Sneha Prasad (snpd) wrote :

I would like to work on this issue, what is the expected change in the code?

Sneha Prasad (snpd)
Changed in manila:
assignee: nobody → Sneha Prasad (snpd)
Jason Grosso (jgrosso)
Changed in manila:
status: New → Triaged
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to manila (master)

Fix proposed to branch: master
Review: https://review.openstack.org/648755

Changed in manila:
status: Triaged → In Progress
Revision history for this message
Jason Grosso (jgrosso) wrote :

Sneha is there any update to this bug?

Revision history for this message
Sneha Prasad (snpd) wrote :

Jason, I am not sure what is the change required here. Should segmentation_id be a list so that all the segment IDs will be appended to it or any other modification is required. It will be helpful if I receive a suggestion on this.

Revision history for this message
Vida Haririan (vhariria) wrote :
Revision history for this message
Felipe Rodrigues (felipefutty) wrote :

I was able to reproduce the bug using the Netapp drive with multi-segmentation. Enabling the segments extension in neutron.conf and creating the net, segments and subnets as described. Then, creating the 3 manila share-network with its shares. Showing the share-network the "segmentaion_id" is set as same value for all of them!

To solve the bug I faced a problem: I could not retrieve the segmentation value of a given subnet. The subnet entity has only the segmenation_id, without the segmenation value though. Also, the neutron sdk used by the manila project (python-neutronclient) has not implemented segment CRUD (for retrieving the value given id).

There are some possible approaches:

1. Replace the neutron sdk by the openstacksdk (it has the segment CRUD). It may break other network requests on manila!

2. Changing neutron entity net, adding the segment id to each segment. So, we'd be able to get the segmentation value by manually matching net and subnet segment information.

3. Implement segment CRUD on python-neutronclient.

Revision history for this message
Goutham Pacha Ravi (gouthamr) wrote :

More discussion on the bug happened on the #openstack-manila channel on Freenode:

http://eavesdrop.openstack.org/irclogs/%23openstack-manila/%23openstack-manila.2020-04-14.log.html#t2020-04-14T21:19:09

The network plugin assumes that the neutron SDK is presenting segments via the network API, and currently, we pick a segment from the neutron network that corresponds to the configured
"[neutron]/neutron_physical_net_name". The code is written in a sort of confusing manner, i.e., instead of picking the segment that corresponds to "neutron_physical_net_name" and bailing out, we continue to process segments, which gives us the impression that the final segment is picked from the list, resulting in the "wrong behavior": https://opendev.org/openstack/manila/src/commit/28bb650128d2207b43f62c6b1d94a9ba46fede5f/manila/network/neutron/neutron_network_plugin.py#L367-L387

However, I believe by looking at the feature/spec and code, for this setup to work, any neutron network should have one segment that corresponds to the physical network, and not more. I don't have sufficient deployment experience to validate this assumption. I'd defer to users that have this setup in their labs to confirm.

Changed in manila:
assignee: Sneha Prasad (snpd) → nobody
importance: Medium → Low
status: In Progress → Opinion
Revision history for this message
Goutham Pacha Ravi (gouthamr) wrote :

More discussion on the #openstack-manila IRC channel on Freenode:

http://eavesdrop.openstack.org/irclogs/%23openstack-manila/%23openstack-manila.2020-04-15.log.html#t2020-04-15T06:32:36

April 14, 2020
[11:32:35 PM]carthaca: gouthamr felipe_rodrigues: re https://bugs.launchpad.net/manila/+bug/1799742 yes we use hierarchical port binding and have multisegment networks
[11:32:37 PM] @openstack Launchpad bug 1799742 in Manila "Wrong segmentation ID sent to drivers when using multi-segments" [Low,Opinion]
[11:32:55 PM] carthaca: gouthamr felipe_rodrigues our segments are in the neutron network and there is always only 1 that matches the corresponding physnet of the manila backend, subnets don't have a different segment
[11:33:45 PM] carthaca: gouthamr felipe_rodrigues: so I don't see the behaviour observed in the bug
April 15, 2020
[06:16:29 AM] gouthamr: carthaca: thank you for the feedback!

--

So, I'm closing this bug as "Invalid". If anything, we can make a low-impact optimization to the for loop here [1] to bail out as soon as we've found the segment that matches the physical network. However, we won't gain much in terms of performance, since it remains O(n).

https://opendev.org/openstack/manila/src/commit/28bb650128d2207b43f62c6b1d94a9ba46fede5f/manila/network/neutron/neutron_network_plugin.py#L367-L387

Changed in manila:
status: Opinion → Invalid
Revision history for this message
Felipe Rodrigues (felipefutty) wrote :
Download full text (5.0 KiB)

Using: Netapp drive (vlan support) as dhss true!

To reproduce the bug, it is required to enable segmentation extension
in neutron config file and add the physical net name in the manila config
file (neutron_physical_net_name). Then, follow:

1. Create a segmented net:

$ openstack network create segmented-net

2. Crate 3 segmenets in the segmented net:

$ openstack network segment create --network-type vlan --network segmented-net --segment 350 segment-350 --physical-network physnet1
$ openstack network segment create --network-type vlan --network segmented-net --segment 360 segment-360 --physical-network physnet1
$ openstack network segment create --network-type vlan --network segmented-net --segment 370 segment-370 --physical-network physnet1

3. Create 3 subnetes in the segmented net, being each one linked to one of the previous created segments:

$ openstack subnet create --subnet-range 192.168.101.0/24 --dhcp --gateway 192.168.101.1 --network segmented-net seg350-subnet --network-segment segment-350
$ openstack subnet create --subnet-range 192.168.102.0/24 --dhcp --gateway 192.168.102.1 --network segmented-net seg360-subnet --network-segment segment-360
$ openstack subnet create --subnet-range 192.168.103.0/24 --dhcp --gateway 192.168.103.1 --network segmented-net seg370-subnet --network-segment segment-370

4. Show the segmented net for getting the net id and subnets id:

$ openstack network show segmented-net

The fields that matter:
| id | 1147ddf4-f9a3-4609-862f-83e06a7fb51c |
| segments | [{'provider:network_type': 'vlan', 'provider:physical_network': 'physnet1', 'provider:segmentation_id': 3556}, {'provider:network_type': 'vlan', 'provider:physical_network': 'physnet1', 'provider:segmentation_id': 350}, {'provider:network_type': 'vlan', 'provider:physical_network': 'physnet1', 'provider:segmentation_id': 360}, {'provider:network_type': 'vlan', 'provider:physical_network': 'physnet1', 'provider:segmentation_id': 370}] |
| subnets | 188b25c0-a7f8-4733-8096-e37d2cce8a20, a99f32a6-6ecc-4aa0-9e14-5b0e672832d9, ee1f537e-6d21-4d64-bc89-8b22dfc8788c |

5. Getting the previous ids, create 3 manila share-net in the segmented net,
being each one linked to one of the subnets:

$ manila share-network-create --neutron-net-id 1147ddf4-f9a3-4609-862f-83e06a7fb51c --neutron-subnet-id 188b25c0-a7f8-4733-8096-e37d2cce8a20 --name share-seg350

- The output field share network subnets has segmentation_id None:
| share_network_subnets | [{'id': '44362247-a3ec-4921-97a9-5e6622e4be31', 'availability_zone': None, 'created_at': '2020-04-15T13:45:27.000000', 'updated_at': None, 'segmentation_id': None, 'neutron_net_id': '1147ddf4-f9a3-4609-862f-83e06a7fb51c', 'neutron_subnet_id': '188b25c0-a7f8-4733-8096-e37d2cce8a20', 'ip_version': None, 'cidr': None, 'network_type': None, 'mtu': None, 'gateway': None}] |

$ manila share-network-create --neutron-net-id 1147ddf4-f9a3-4609-862f-83e06a7fb51c --neutron-subnet-id ee1f537e-6d21-4d64-bc89-8b22dfc8788c --name share-seg360

- The output field share network subnets has segme...

Read more...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.