yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #82910
[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