openstack network segment range create failed

[Juan Carlos Alonso]

Title
-----
openstack network segment range create FAILED

Brief Description
-----------------
In “Providernetworking setup: Network Segment Ranges (Stein)” section, in the second command:

$: openstack network segment range create ${PHYSNET0}-b --network-type vlan --physical-network ${PHYSNET0} --minimum 10 --maximum 10 --shared

I got the following error:

BadRequestException: 400: Client Error for url: http://neutron.openstack.svc.cluster.local:80/v2.0/network_segment_ranges, Invalid input for tenant_id. Reason: 'None' is not a valid string.

I tried to add --project ${ADMINID} but --project is only allowed with --private.

Severity
--------
<Critical: System/Feature is not usable after the defect>

Steps to Reproduce
------------------
$: openstack network segment range create ${PHYSNET0}-b --network-type vlan --physical-network ${PHYSNET0} --minimum 10 --maximum 10 --shared

Expected Behavior
------------------
Network segment range created succesfully

Actual Behavior
----------------
BadRequestException: 400: Client Error for url: http://neutron.openstack.svc.cluster.local:80/v2.0/network_segment_ranges, Invalid input for tenant_id. Reason: 'None' is not a valid string.

Reproducibility
---------------
<Reproducible/100%>

System Configuration
--------------------
Any in virtual and Bare Metal environment

[Kailun Qin (kailun.qin)]

This is a regression issue due to the requirement change of the network-segment-range OSC CLI during the feature patch review.
I’ve filed bugs [1][2] and submitted patches [3][4] for them.
Please kindly note that [3] would be enough to address this issue, while [4] is an enhancement of semantic check based on the latest alignment on the requirement of network-segment-range OSC CLI behavior.

[1] https://storyboard.openstack.org/#!/story/2005205
[2] https://storyboard.openstack.org/#!/story/2005206
[3] https://review.openstack.org/#/c/642707/
[4] https://review.openstack.org/#/c/642708/

[Ghada Khalil (gkhalil)]

This issue was introduced in StarlingX on March 8 after picking up the latest openstack client code which included the following commit related to network segment range:
https://github.com/openstack/python-openstackclient/commit/6868499ad9443960a158143c923da00ea86b7072

See https://bugs.launchpad.net/starlingx/+bug/1819176 for more details.

It appears that the network segment range code was changed before the merge and is now causing issues. Subsequent code changes are required in the openstack client code to address the issue. These are tracked by the following:
https://storyboard.openstack.org/#!/story/2005205
https://storyboard.openstack.org/#!/story/2005206
https://review.openstack.org/#/c/642707/
https://review.openstack.org/#/c/642708/

[Ghada Khalil (gkhalil)]

Workaround: Do not specify --shared and it’ll default to a shared range.

[Juan Carlos Alonso (juancarlosa)]

Workaround works correctly on our side.

[Kailun Qin (kailun.qin)]

The issue was not discovered due to a functional test bug [1] in openstackclient. The functional test for network segment range was skipped unexpectedly because of this.
Now we've added tests at unit level [2] to have it covered.

[1] https://review.openstack.org/#/c/642074/
[2] https://review.openstack.org/#/c/642707/

[Kailun Qin (kailun.qin)]

The fix which directly addresses this issue [1] has been merged into python-openstackclient already.

[1] https://review.openstack.org/#/c/642707/

[Ghada Khalil (gkhalil)]

Reducing the priority to high since there is a workaround

[Ghada Khalil (gkhalil)]

The openstack-client code has merged as of March 15:
https://review.openstack.org/#/c/642707/
https://review.openstack.org/#/c/642708/
https://review.openstack.org/#/c/642074/

There is also a starlingx review to pick up master openstack-client when building the wheels:
https://review.openstack.org/#/c/644381/

[Ghada Khalil (gkhalil)]

https://review.openstack.org/#/c/644381/ is included in cengn build: 20190318T233000Z