openstack/python-openstackclient
Code Issues Proposed changes
0a7f2692c6
python-openstackclient/doc/source/cli/command-objects/network_segment_range.rst

15 lines
469 B
ReStructuredText
Raw Normal View History

Add network segment range command object Add network segment range command object in support of network segment range management. This patch set includes documentation, unit tests and functional tests (currently skipped unit network segment range enabled in Neutron by default) for the following new commands: - "os network segment range create" - "os network segment range delete" - "os network segment range list" - "os network segment range set" - "os network segment range show" Co-authored-by: Allain Legacy <Allain.legacy@windriver.com> [depends on removed by dtroyer as those are all +W and trying to pass the gate, OSC has it's freeze dealine looming] Depends: https://review.openstack.org/624708 Depends: https://review.openstack.org/624709 Depends: https://review.openstack.org/638386 Partially-implements: blueprint network-segment-range-management Change-Id: I335692f2db5be07c1c164f09b13f1abb80b7ba33
2019-02-27 23:02:52 +08:00
=====================
network segment range
=====================
A **network segment range** is a resource for tenant network segment
allocation.
A network segment range exposes the segment range management to be administered
via the Neutron API. In addition, it introduces the ability for the
administrator to control the segment ranges globally or on a per-tenant basis.
Network v2
neutron: autogenerate docs $namespace = openstack.network.v2 The subcommand documents for $namespace were hardcoded and thus prone to drift over time. This commit removes the hardcoded content and uses the autoprogram-cliff directive to generate them automatically from the subcommand configuration classes. This one turned out to be quite involved, because we support both neutron and nova-network. When running in a real cloud, the command classes detect whether the neutron service is present, assume nova-network if that service is not found, and only add parser options relevant to the detected service. But the docs need to present both sets of options. This was easy enough when they were hardcoded, but required a bit of additional infrastructure for generated docs. Change-Id: I426261eb1d86bcc68656aabd61f10b7f082da402
2019-10-28 17:27:38 -05:00
.. autoprogram-cliff:: openstack.network.v2
:command: network segment range *
Copy Permalink