Activity log for bug #1573197

Date Who What changed Old value New value Message
2016-04-21 19:19:57 Sukhdev Kapur bug added bug
2016-04-21 22:08:34 Doug Wiegley neutron: status New Invalid
2016-05-03 00:00:13 Carl Baldwin neutron: status Invalid Incomplete
2016-05-11 10:33:32 Sukhdev Kapur description Neutron networks are, by default, assumed to be single segmented L2 domains, represented by a single segmentation ID (e.g VLAN ID). Current neutron API (neutron net-show) works well with this model. However, with the introduction of HPB, this assumption is not true anymore. Networks are now multi-segmented. A given network could have anywhere from 3 to N number of segments depending upon the breadth/size of the data center topology. This will be true with the implementation of routed networks as well. In general, the segments, in multi-segmented networks, will be dynamically created. As mentioned earlier, the number of these segments will grow and shrink dynamically representing the breadth of data center topology. Therefore, at the very least, admins would like to have visibility into these segments - e.g. which segmentation type/id is consumed in which segment of the network. Venders and Operators are forced to come up with their hacks to get such visibility. This RFE proposes that we enhance neutron API to address this visibility issue in a vendor/implementation agnostic way - by either enhancing "neutron net-show" or by introducing additional commands such as "neutron net-segments-list/neutron net-segment-show". This capability is needed for Neutron-Manila integration as well. Manila requires visibility into the segmentation IDs used in specific segments of a network. Please see Manila use case here - https://wiki.openstack.org/wiki/Manila/design/manila-newton-hpb-support This FRE 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.
2016-05-11 16:37:50 Andreas Scheuring bug added subscriber Andreas Scheuring
2016-05-11 18:06:36 Carl Baldwin description This FRE 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. 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.
2016-05-11 18:06:42 Carl Baldwin neutron: status Incomplete Triaged
2016-05-12 10:08:52 Dr. Jens Harbott bug added subscriber Dr. Jens Rosenboom
2017-02-01 01:07:18 Armando Migliaccio neutron: status Triaged Incomplete
2017-02-01 01:25:12 Armando Migliaccio neutron: importance Undecided Wishlist
2017-02-01 01:25:16 Armando Migliaccio tags rfe
2017-04-02 04:19:59 Launchpad Janitor neutron: status Incomplete Expired