← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1882800] [NEW] Provide network segment information in a consistent way

 

Public bug reported:

Some Neutron client services (Nova, OSC, neutron-client) should receive
a consistent "network" information. Every Neutron network has, at least,
one segment. Regardless of the number of segments, this information,
passed in a dictionary, should always contain the "segments" key.

For example, in Nova [1], when the network information is retrieved,
first the "segments" are pulled from the Neutron server. If this
information is empty, then the "provider" parameters are requested.

In OSC and neutron-client, the segment information should be represented
always in the same way, regardless of the number of segments.
"provider:*" parameters are a legacy leftover. Instead of this, a list
of segments (one or many), should be always presented:

 segments     | [{'provider:network_type': 'vlan',
               'provider:physical_network': 'public',
               'provider:segmentation_id': 10}, ...

This change should be done with care to not break any out-of-tree
extension or driver reading the information as is now.

[1]https://github.com/openstack/nova/blob/6bbc46c546502c368ca251d45213e7918dd21e86/nova/network/neutron.py#L2011-L2027

** Affects: neutron
     Importance: Undecided
         Status: New

** Description changed:

  Some Neutron client services (Nova, OSC, neutron-client) should receive
  a consistent "network" information. Every Neutron network has, at least,
  one segment. Regardless of the number of segments, this information,
  passed in a dictionary, should always contain the "segments" key.
  
  For example, in Nova [1], when the network information is retrieved,
  first the "segments" are pulled from the Neutron server. If this
  information is empty, then the "provider" parameters are requested.
  
  In OSC and neutron-client, the segment information should be represented
  always in the same way, regardless of the number of segments.
  "provider:*" parameters are a legacy leftover. Instead of this, a list
  of segments (one or many), should be always presented:
  
-  segments     | [{'provider:network_type': 'vlan', 'provider:physical_network': 'public',
-                   'provider:segmentation_id': 10}, ...
+  segments     | [{'provider:network_type': 'vlan', 
+                   'provider:physical_network': 'public',
+                   'provider:segmentation_id': 10}, ...
  
- 
- This change should be done with care to not break any out-of-tree extension or driver reading the information as is now.
- 
+ This change should be done with care to not break any out-of-tree
+ extension or driver reading the information as is now.
  
  [1]https://github.com/openstack/nova/blob/6bbc46c546502c368ca251d45213e7918dd21e86/nova/network/neutron.py#L2011-L2027

** Description changed:

  Some Neutron client services (Nova, OSC, neutron-client) should receive
  a consistent "network" information. Every Neutron network has, at least,
  one segment. Regardless of the number of segments, this information,
  passed in a dictionary, should always contain the "segments" key.
  
  For example, in Nova [1], when the network information is retrieved,
  first the "segments" are pulled from the Neutron server. If this
  information is empty, then the "provider" parameters are requested.
  
  In OSC and neutron-client, the segment information should be represented
  always in the same way, regardless of the number of segments.
  "provider:*" parameters are a legacy leftover. Instead of this, a list
  of segments (one or many), should be always presented:
  
-  segments     | [{'provider:network_type': 'vlan', 
-                   'provider:physical_network': 'public',
-                   'provider:segmentation_id': 10}, ...
+  segments     | [{'provider:network_type': 'vlan',
+             'provider:physical_network': 'public',
+             'provider:segmentation_id': 10}, ...
  
  This change should be done with care to not break any out-of-tree
  extension or driver reading the information as is now.
  
  [1]https://github.com/openstack/nova/blob/6bbc46c546502c368ca251d45213e7918dd21e86/nova/network/neutron.py#L2011-L2027

** Description changed:

  Some Neutron client services (Nova, OSC, neutron-client) should receive
  a consistent "network" information. Every Neutron network has, at least,
  one segment. Regardless of the number of segments, this information,
  passed in a dictionary, should always contain the "segments" key.
  
  For example, in Nova [1], when the network information is retrieved,
  first the "segments" are pulled from the Neutron server. If this
  information is empty, then the "provider" parameters are requested.
  
  In OSC and neutron-client, the segment information should be represented
  always in the same way, regardless of the number of segments.
  "provider:*" parameters are a legacy leftover. Instead of this, a list
  of segments (one or many), should be always presented:
  
   segments     | [{'provider:network_type': 'vlan',
-             'provider:physical_network': 'public',
-             'provider:segmentation_id': 10}, ...
+               'provider:physical_network': 'public',
+               'provider:segmentation_id': 10}, ...
  
  This change should be done with care to not break any out-of-tree
  extension or driver reading the information as is now.
  
  [1]https://github.com/openstack/nova/blob/6bbc46c546502c368ca251d45213e7918dd21e86/nova/network/neutron.py#L2011-L2027

** Description changed:

  Some Neutron client services (Nova, OSC, neutron-client) should receive
  a consistent "network" information. Every Neutron network has, at least,
  one segment. Regardless of the number of segments, this information,
  passed in a dictionary, should always contain the "segments" key.
  
  For example, in Nova [1], when the network information is retrieved,
  first the "segments" are pulled from the Neutron server. If this
  information is empty, then the "provider" parameters are requested.
  
  In OSC and neutron-client, the segment information should be represented
  always in the same way, regardless of the number of segments.
  "provider:*" parameters are a legacy leftover. Instead of this, a list
  of segments (one or many), should be always presented:
  
   segments     | [{'provider:network_type': 'vlan',
-               'provider:physical_network': 'public',
-               'provider:segmentation_id': 10}, ...
+                'provider:physical_network': 'public',
+                'provider:segmentation_id': 10}, ...
  
  This change should be done with care to not break any out-of-tree
  extension or driver reading the information as is now.
  
  [1]https://github.com/openstack/nova/blob/6bbc46c546502c368ca251d45213e7918dd21e86/nova/network/neutron.py#L2011-L2027

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1882800

Title:
  Provide network segment information in a consistent way

Status in neutron:
  New

Bug description:
  Some Neutron client services (Nova, OSC, neutron-client) should
  receive a consistent "network" information. Every Neutron network has,
  at least, one segment. Regardless of the number of segments, this
  information, passed in a dictionary, should always contain the
  "segments" key.

  For example, in Nova [1], when the network information is retrieved,
  first the "segments" are pulled from the Neutron server. If this
  information is empty, then the "provider" parameters are requested.

  In OSC and neutron-client, the segment information should be
  represented always in the same way, regardless of the number of
  segments. "provider:*" parameters are a legacy leftover. Instead of
  this, a list of segments (one or many), should be always presented:

   segments     | [{'provider:network_type': 'vlan',
                 'provider:physical_network': 'public',
                 'provider:segmentation_id': 10}, ...

  This change should be done with care to not break any out-of-tree
  extension or driver reading the information as is now.

  [1]https://github.com/openstack/nova/blob/6bbc46c546502c368ca251d45213e7918dd21e86/nova/network/neutron.py#L2011-L2027

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1882800/+subscriptions


Follow ups