[RFE] Neutron API enhancement for visibility into multi-segmented networks

[Sukhdev Kapur]

This RFE is filed for Manila-Neutron integration in mind.
Manila is shared FS as a Service and wants to leverage neutron networks for multi-tenancy support. Typically, storage clusters will be connected to select TORs, therefore, most of the neutron networks utilized by Manila deployments will be multi-segmented networks.

Please see Manila use case here - https://wiki.openstack.org/wiki/Manila/design/manila-newton-hpb-support

With HPB, as ML2 drivers dynamically create segments, they select the segmentation-type and segmentation-Ids dynamically as they are binding the port of a specific instance to host (and or TOR). While this information is available in ML2 drivers, it is not visible to users or admins. There is no mechanism in neutron API to provide such information to users.

For example, in a typical deployment, a user creates a neutron network (net-A) and boots an instance and attaches to the net-A. For any reason (such as debug-ability), they can see what segmentation-type or segmentation-id is associated with the instance by simply using "neutron net-show net-A". They can build automation by using neutron API to get visibility into the connectivity information. With HPB, this information is not available. Therefore, for the users of multi-segmented networks, such information is lost - hence, Manila is looking for a cleaner way from Neutron to provide such information. Moreover, this is a generic problem for operators with the HPB - i.e no visibility.

Routed networks is providing visibility into the multi-segmented networks through a new CRUD API described here - https://review.openstack.org/#/c/225384/22/specs/newton/routed-networks.rst
However, this does not have any port specific information - i.e. ability to see which port is bound to which segment.

[Doug Wiegley (dougwig)]

Isn't this a dup of this spec, that is in progress? https://review.openstack.org/#/c/225384/22/specs/newton/routed-networks.rst

[Carl Baldwin (carl-baldwin)]

Does this get you started: https://review.openstack.org/296603 ?

[Sukhdev Kapur (sukhdev-8)]

I chatted with Carl. Looks like this patch, along with the follow on patches which xiaohhui will be working on integrating with ML2 and OVN will do the trick. Therefore, we are OK to ignore this RFE for now.
-Sukhdev

[Carl Baldwin (carl-baldwin)]

After talking with Sukhdev and a Manila person at the summit on Friday and looking at the Manila use case, I understand much better what the use case is you're after here. An ML2 mechanism driver that will bind the port to the Manila file server will have access to all of the details it needs. Wouldn't it? I tend to that that we should be thinking along those lines instead of thinking about exposing all of the internal details through the API so that Manila can connect to neutron networks outside of Neutron.

At the summit, I asked that this request be written in terms of the higher level use case needed by Manila, instead of that use case being presented as an after-thought at the end of the description. Actually, the link to the Manila use case [1] is a pretty good start. If you can do that, it will be the start of a decent discussion.

[1] https://wiki.openstack.org/wiki/Manila/design/manila-newton-hpb-support

[Sukhdev Kapur (sukhdev-8)]

Updated RFE based upon the discussion during Austin Summit - to make it more specific to Manila-neutron integration use case. See Carl's note above

[Armando Migliaccio (armando-migliaccio)]

This bug is > 180 days without activity. We are unsetting assignee and milestone and setting status to Incomplete in order to allow its expiry in 60 days.

If the bug is still valid, then update the bug status.

[Launchpad Janitor (janitor)]

[Expired for neutron because there has been no activity for 60 days.]