Patch [0] dropped mapping the tenant_id attribute to project_id.
However, the Neutron API still returns the tenant_id attribute in
addition to the project_id and so we still need to discard it from
the output.
[0] I5f62f2a76592eaaaed6703624e959df41a6ecc8f
Signed-off-by: Dr. Jens Harbott <harbott@osism.tech>
Change-Id: Iba1e003bf587802f28928cb44d160b3b3fb1f840
There were a number of 'get_osc_show_columns_for_sdk_resource' defined
in-tree. However, osc-lib has provided this method for some time (since
2.2.0, June 2020 [1] - our minimum version is currently 2.3.0) so
there's no need to provide our own copies. Remove them.
[1] https://github.com/openstack/osc-lib/commit/29a0c5a5
Change-Id: I25695f4f9a379dd691b7eaa1e3247164668ae77e
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
To deprecate and drop support for neutronclient CLI and use only
OSC we need feature parity between OSC and neutronclient.
Last missing piece here is possibility to send in POST/PUT requests
unknown parameters to the Neutron server.
This patch adds such possibility to the OSC.
Change-Id: Iba09297c2be9fb9fa0be1b3dc65755277b79230e
This function should return an ordered set of ranges based on an
unordered list of numbers (int or str).
Change-Id: I918c8befc51236cc33d96a5c88fb6eafdd143e9c
Story: 2007341
Task: 38878
1. As mentioned in [1], we should avoid using six.iteritems to achieve
iterators. We can use dict.items instead, as it will return iterators
in PY3 as well. And dict.items/keys will more readable.
2. In py2, the performance about list should be negligible,
see the link [2].
[1] https://wiki.openstack.org/wiki/Python3
[2] http://lists.openstack.org/pipermail/openstack-dev/2015-June/066391.html
Co-Authored-By: Akihiro Motoki <amotoki@gmail.com>
Change-Id: I4b9edb326444264c0f6c4ad281acaac356a07e85
Implements: blueprint replace-iteritems-with-items
These return a Munch from the SDK, which can be handled exactly
like a dict so do that.
Note that the location column has a nested project dict in the
return value, this is addressed separately in osc_lib.format_columns
in https://review.opendev.org/#/c/679474/.
Change-Id: I99a6d192749a4ac76777f72be8118261c0521cb0
Signed-off-by: Dean Troyer <dtroyer@gmail.com>
Pick up newer versions of this library. Thankfully no serious changes
are needed.
Change-Id: I69e523844529fc1c8aa0c1ce764182dbe29cfeb6
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
When neither of "--shared" and "--private" is input, we should not allow
to specify "--project". Defaulting the created network segment range to
shared is expected. Therefore, "project_id" attr should only be
populated on a private range creation.
Change-Id: Iab345e1651dd8b7904ff64a20633f194d719bb84
Story: 2005206
Task: 29980
"project_id" attribute should not be set to None on shared network
segment range creation since it is not a valid string type which is
required for the API.
Change-Id: Ia2bab12e39b4bb7e05ff2acfffb851252c100651
Story: 2005205
Task: 29975
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