Remove the CLI code from the Neutron client.

This project no longer provides CLI support. All code has been
removed. Please use openstack CLI instead

This patch removes entry point for neutron CLI too, bash completion
script and CLI related functional and unit tests but it
still keeps neutronclient/neutron/v2_0 module as this is used by e.g.
Nova.

Co-Authored-By: Slawek Kaplonski <skaplons@redhat.com>

Closes-Bug: #2003861
Change-Id: I5b6c735d1ff931d7991a42b262e7faa47b75edeb
This commit is contained in:
Slawek Kaplonski 2023-04-11 13:12:45 +02:00
parent 3071dfbd0f
commit 52653c95e0
93 changed files with 22 additions and 15350 deletions

View File

@ -7,12 +7,6 @@
- lib-forward-testing-python3
- release-notes-jobs-python3
- openstackclient-plugin-jobs
check:
jobs:
- neutronclient-functional
gate:
jobs:
- neutronclient-functional
experimental:
jobs:
- neutronclient-grenade-neutron-lib:
@ -20,52 +14,6 @@
- ^(test-|)requirements.txt$
- ^setup.cfg$
- job:
name: neutronclient-functional
parent: devstack-tox-functional
irrelevant-files:
- ^.*\.rst$
- ^doc/.*$
- ^releasenotes/.*$
required-projects:
- openstack/python-neutronclient
- openstack/neutron
- openstack/neutron-vpnaas
vars:
tox_envlist: functional
devstack_services:
# NOTE: neutronclient.tests.functional.base.ClientTestBase does not
# support HTTPS endpoints now, so tls-proxy needs to be disabled.
tls-proxy: false
# Disable OVN services
br-ex-tcpdump: false
br-int-flows: false
ovn-controller: false
ovn-northd: false
ovs-vswitchd: false
ovsdb-server: false
q-ovn-metadata-agent: false
# Neutron services
q-agt: true
q-dhcp: true
q-l3: true
q-meta: true
neutron-network-segment-range: true
neutron-segments: true
q-metering: true
q-qos: true
neutron-tag-ports-during-bulk-creation: true
neutron-conntrack-helper: true
devstack_localrc:
USE_PYTHON3: true
LIBS_FROM_GIT: python-neutronclient
Q_AGENT: openvswitch
Q_ML2_TENANT_NETWORK_TYPE: vxlan
Q_ML2_PLUGIN_MECHANISM_DRIVERS: openvswitch
devstack_plugins:
neutron: https://opendev.org/openstack/neutron
neutron-vpnaas: https://opendev.org/openstack/neutron-vpnaas
- job:
name: neutronclient-grenade-neutron-lib
parent: grenade

View File

@ -15,8 +15,7 @@ Python bindings to the Neutron API
:alt: Latest Version
This is a client library for Neutron built on the Neutron API. It
provides a Python API (the ``neutronclient`` module) and a command-line tool
(``neutron``).
provides a Python API (the ``neutronclient`` module).
* License: Apache License, Version 2.0
* `PyPi`_ - package installation

View File

@ -24,10 +24,9 @@
Using CLI
=========
There are two CLIs which support the Networking API:
`OpenStackClient (OSC)
There is `OpenStackClient (OSC)
<https://docs.openstack.org/python-openstackclient/latest/>`__
and :doc:`neutron CLI <neutron>` (deprecated).
which support the Networking API
OpenStackClient
---------------
@ -49,15 +48,8 @@ neutron CLI
.. warning::
neutron CLI is now deprecated and will be removed in the future.
Use openstack CLI instead. See `openstack CLI command list
neutron CLI is removed. Use openstack CLI instead. See `openstack CLI command list
<https://docs.openstack.org/python-openstackclient/latest/cli/command-list.html>`__
and :doc:`its extensions for advanced networking services <osc_plugins>`.
The command mapping from neutron CLI to openstack CLI is available
`here <https://docs.openstack.org/python-openstackclient/latest/cli/decoder.html#neutron-cli>`__.
.. toctree::
:maxdepth: 2
neutron CLI guide <neutron>
neutron CLI reference <neutron-reference>

View File

@ -1,48 +0,0 @@
..
Licensed under the Apache License, Version 2.0 (the "License"); you may
not use this file except in compliance with the License. You may obtain
a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations
under the License.
Convention for heading levels in Neutron devref:
======= Heading 0 (reserved for the title in a document)
------- Heading 1
~~~~~~~ Heading 2
+++++++ Heading 3
''''''' Heading 4
(Avoid deeper levels because they do not render well.)
=====================
neutron CLI reference
=====================
.. warning::
neutron CLI is now deprecated and will be removed in the future.
Use openstack CLI instead. See `openstack CLI command list
<https://docs.openstack.org/python-openstackclient/latest/cli/command-list.html>`__
and :doc:`its extensions for advanced networking services <osc_plugins>`.
The command mapping from neutron CLI to openstack CLI is available
`here <https://docs.openstack.org/python-openstackclient/latest/cli/decoder.html#neutron-cli>`__.
neutron usage
-------------
.. autoprogram-cliff:: neutronclient.shell.NeutronShell
:application: neutron
:arguments: 2.0
neutron API v2.0 commands
-------------------------
.. autoprogram-cliff:: neutron.cli.v2
:application: neutron

View File

@ -1,412 +0,0 @@
..
Licensed under the Apache License, Version 2.0 (the "License"); you may
not use this file except in compliance with the License. You may obtain
a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations
under the License.
Convention for heading levels in Neutron devref:
======= Heading 0 (reserved for the title in a document)
------- Heading 1
~~~~~~~ Heading 2
+++++++ Heading 3
''''''' Heading 4
(Avoid deeper levels because they do not render well.)
Using neutron CLI
=================
The **neutron** shell utility interacts with OpenStack Networking API from the
command-line. It supports the entire features of OpenStack Networking API.
.. warning::
neutron CLI is now deprecated and will be removed in the future.
Use openstack CLI instead. See `openstack CLI command list
<https://docs.openstack.org/python-openstackclient/latest/cli/command-list.html>`__
and :doc:`its extensions for advanced networking services <osc_plugins>`.
The command mapping from neutron CLI to openstack CLI is available
`here <https://docs.openstack.org/python-openstackclient/latest/cli/decoder.html#neutron-cli>`__.
Basic Usage
-----------
In order to use the CLI, you must provide your OpenStack username, password,
project, domain information for both user and project, and auth endpoint. Use
the corresponding configuration options (``--os-username``, ``--os-password``,
``--os-project-name``, ``--os-user-domain-id``, ``os-project-domain-id``, and
``--os-auth-url``), but it is easier to set them in environment variables.
.. code-block:: shell
export OS_USERNAME=user
export OS_PASSWORD=pass
export OS_PROJECT_NAME=project
export OS_USER_DOMAIN_ID=default
export OS_PROJECT_DOMAIN_ID=default
export OS_AUTH_URL=http://auth.example.com:5000/v3
If you are using Identity v2.0 API (DEPRECATED), you don't need to pass domain
information.
.. code-block:: shell
export OS_USERNAME=user
export OS_PASSWORD=pass
export OS_TENANT_NAME=tenant
export OS_AUTH_URL=http://auth.example.com:5000/v2.0
Once you've configured your authentication parameters, you can run **neutron**
commands. All commands take the form of:
.. code-block:: none
neutron <command> [arguments...]
Run **neutron help** to get a full list of all possible commands, and run
**neutron help <command>** to get detailed help for that command.
Using with os-client-config
~~~~~~~~~~~~~~~~~~~~~~~~~~~
`os-client-config <https://docs.openstack.org/os-client-config/latest/>`_
provides more convenient way to manage a collection of client configurations
and you can easily switch multiple OpenStack-based configurations.
To use os-client-config, you first need to prepare
``~/.config/openstack/clouds.yaml`` like the following.
.. code-block:: yaml
clouds:
devstack:
auth:
auth_url: http://auth.example.com:5000
password: your-secret
project_domain_id: default
project_name: demo
user_domain_id: default
username: demo
identity_api_version: '3'
region_name: RegionOne
devstack-admin:
auth:
auth_url: http://auth.example.com:35357
password: another-secret
project_domain_id: default
project_name: admin
user_domain_id: default
username: admin
identity_api_version: '3'
region_name: RegionOne
Then, you need to specify a configuration name defined in the above clouds.yaml.
.. code-block:: shell
export OS_CLOUD=devstack
For more detail information, see the
`os-client-config <https://docs.openstack.org/os-client-config/latest/>`_
documentation.
Using with keystone token
~~~~~~~~~~~~~~~~~~~~~~~~~
The command-line tool will attempt to re-authenticate using your provided
credentials for every request. You can override this behavior by manually
supplying an auth token using ``--os-url`` and ``--os-auth-token``. You can
alternatively set these environment variables.
.. code-block:: shell
export OS_URL=http://neutron.example.org:9696/
export OS_TOKEN=3bcc3d3a03f44e3d8377f9247b0ad155
Using noauth mode
~~~~~~~~~~~~~~~~~
If neutron server does not require authentication, besides these two arguments
or environment variables (We can use any value as token.), we need manually
supply ``--os-auth-strategy`` or set the environment variable.
.. code-block:: shell
export OS_AUTH_STRATEGY=noauth
Display options
---------------
Filtering
~~~~~~~~~
Neutron API supports filtering in the listing operation.
**neutron** CLI supports this feature too.
To specify a filter in ``*-list`` command, you need to pass a pair of an
attribute name and an expected value with the format of ``--<attribute> <value>``.
The example below retrieves ports owned by compute instances.
.. code-block:: console
$ neutron port-list --device_owner network:dhcp
+--------------------------------------+------+-------------------+-------------------------------------------------------------------------------------------------------------+
| id | name | mac_address | fixed_ips |
+--------------------------------------+------+-------------------+-------------------------------------------------------------------------------------------------------------+
| 8953d683-29ad-4be3-b73f-060727c7849b | | fa:16:3e:4b:9e:0a | {"subnet_id": "6b832dfe-f271-443c-abad-629961414a73", "ip_address": "10.0.0.2"} |
| | | | {"subnet_id": "cdcc616b-0cff-482f-96f5-06fc63d21247", "ip_address": "fd12:877c:1d66:0:f816:3eff:fe4b:9e0a"} |
+--------------------------------------+------+-------------------+-------------------------------------------------------------------------------------------------------------+
You can also specify multiple filters.
The example below retrieves security group rules applied to IPv4 traffic
which belongs to a security group bfa493f9-2b03-46d2-8399-b9b038a53bc1.
.. code-block:: console
$ neutron security-group-rule-list --security-group-id bfa493f9-2b03-46d2-8399-b9b038a53bc1 --ethertype IPv4
+--------------------------------------+----------------+-----------+-----------+---------------+-----------------+
| id | security_group | direction | ethertype | protocol/port | remote |
+--------------------------------------+----------------+-----------+-----------+---------------+-----------------+
| 65489805-0400-4bce-9bd9-16a81952263c | default | egress | IPv4 | any | any |
| 9429f336-4947-4643-bbd9-24528cc65648 | default | ingress | IPv4 | any | default (group) |
+--------------------------------------+----------------+-----------+-----------+---------------+-----------------+
.. note::
Looking up UUID from name is not supported when specifying a filter.
You need to use UUID to specify a specific resource.
.. note::
Filtering for dictionary or list attributes is not supported.
Changing displayed columns
~~~~~~~~~~~~~~~~~~~~~~~~~~
If you want displayed columns in a list operation, ``-c`` option can be used.
``-c`` can be specified multiple times and the column order will be same as
the order of ``-c`` options.
.. code-block:: console
$ neutron port-list -c id -c device_owner -c fixed_ips
+--------------------------------------+--------------------------+-------------------------------------------------------------------------------------------------------------+
| id | device_owner | fixed_ips |
+--------------------------------------+--------------------------+-------------------------------------------------------------------------------------------------------------+
| 41ca1b9b-4bbd-4aa8-bcaa-31d3d5704205 | network:router_interface | {"subnet_id": "6b832dfe-f271-443c-abad-629961414a73", "ip_address": "10.0.0.1"} |
| 8953d683-29ad-4be3-b73f-060727c7849b | network:dhcp | {"subnet_id": "6b832dfe-f271-443c-abad-629961414a73", "ip_address": "10.0.0.2"} |
| | | {"subnet_id": "cdcc616b-0cff-482f-96f5-06fc63d21247", "ip_address": "fd12:877c:1d66:0:f816:3eff:fe4b:9e0a"} |
| a9da29f8-4504-4526-a5ce-cd3624fbd173 | neutron:LOADBALANCER | {"subnet_id": "6b832dfe-f271-443c-abad-629961414a73", "ip_address": "10.0.0.3"} |
| | | {"subnet_id": "cdcc616b-0cff-482f-96f5-06fc63d21247", "ip_address": "fd12:877c:1d66:0:f816:3eff:feb1:ab71"} |
| d6a1ff96-0a99-416f-a4d6-65d9614cf64e | compute:nova | {"subnet_id": "6b832dfe-f271-443c-abad-629961414a73", "ip_address": "10.0.0.4"} |
| | | {"subnet_id": "cdcc616b-0cff-482f-96f5-06fc63d21247", "ip_address": "fd12:877c:1d66:0:f816:3eff:fe2c:348e"} |
| f4789225-26d0-409f-8047-82d2c7a87a95 | network:router_interface | {"subnet_id": "cdcc616b-0cff-482f-96f5-06fc63d21247", "ip_address": "fd12:877c:1d66::1"} |
+--------------------------------------+--------------------------+-------------------------------------------------------------------------------------------------------------+
.. _cli_extra_arguments:
Extra arguments for create/update operation
-------------------------------------------
**neutron** CLI has a mechanism called the *extra arguments* for ``*-create``
and ``*-update`` commands. It allows users to specify a set of *unknown
options* which are not defined as options and not shown in the help text.
**Unknown options MUST be placed at the end of the command line.**
*unknown options* will be directly passed to the API layer. By this mechanism,
you can pass an attribute which is not defined in the upstream **neutron**
CLI. For example, when you are developing a new feature which add a new
attribute to an existing resource, it is useful because we can test your
feature without changing the existing neutron CLI.
For example, if you run the following command::
neutron resource-update <ID> --key1 value1 --key2 value2
where ``resource`` is some resource name and ``--key1`` and ``--key2`` are
unknown options, then the following JSON will be sent to the neutron API::
PUT /v2.0/resources/<ID>
{
"resource": {
"key2": "value2",
"key1": "value1"
}
}
Key interpretation
~~~~~~~~~~~~~~~~~~
This means an option name (``--key1`` in this case) must be one of valid
resources of a corresponding resource. An option name ``--foo_bar`` is
recognized as an attribute name ``foo_bar``. ``--foo-bar`` is also interpreted
as an attribute name ``foo_bar``.
Value interpretation
~~~~~~~~~~~~~~~~~~~~
By default, if the number of values is 1, the option value is interpreted as a
string and is passed to the API layer as specified in a command-line.
If the number of values is greater than 1, the option value is interpreted as a
list and the result in the API layer will be same as when specifying a list as
described below.
neutron resource-update <ID> --key1 val1 val2 val3 --key2 val4
In the above example, a value of ``key1`` is interpreted as
``["val1", "val2", "val3"]`` and a value of ``key2`` is interpreted
as ``val4``.
The extra argument mechanism supports more complex value like a list or a dict.
Specify a list value
++++++++++++++++++++
A command-line::
neutron resource-update <ID> --key list=true val1 val2 val3
will send the following in the API layer::
{
"key": [
"val1",
"val2",
"val3"
]
}
.. note::
If you want to specify a list value, it is recommended to specify
``list=true``. When ``list=true`` is specified, specified values are
interpreted as a list even regardless of the number of values.
If ``list=true`` is not specified, specified values are interpreted
depends on the number of values how. If the number of values is more than 2,
the specified values are interpreted as a list. If 1, the value
is interpreted as a string.
Specify a dict value
++++++++++++++++++++
A command-line::
neutron resource-update <ID> --key type=dict key1=val1,key2=val2,key3=val3
will send the following in the API layer::
{
"key": {
"key1": "val1",
"key2": "val2",
"key3": "val3"
}
}
.. note::
``type=bool True/False`` and ``type=int 10`` are also supported.
Specify a list of dicts
+++++++++++++++++++++++
A command-line::
neutron resource-update <ID> --key type=dict list=true key1=val1 key2=val2 key3=val3
will send the following in the API layer::
{
"key": [
{"key1": "val1"},
{"key2": "val2"},
{"key3": "val3"}
]
}
Passing None as a value
~~~~~~~~~~~~~~~~~~~~~~~
There is a case where we would like to pass ``None`` (``null`` in JSON)
in the API layer. To do this::
neutron resource-update <ID> --key action=clear
The following body will be in the API layer::
{"key": null}
.. note::
If ``action=clear`` is specified, ``list=true`` or ``type=dict`` is ignored.
It means when ``action=clear`` is specified ``None`` is always sent.
Debugging
---------
Display API-level communication
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
``-v`` (or ``--verbose``, ``--debug``) option displays a detail interaction
with your neutron server. It is useful to debug what happens in the API level.
Here is an sample output of ``net-show`` command.
The first line show what parameters are recognized by neutronclient.
It is sometimes useful to check if command-line parameters you specify are recognized properly.
.. code-block:: console
$ neutron -v net-show mynetwork
DEBUG: neutronclient.neutron.v2_0.network.ShowNetwork get_data(Namespace(columns=[], fields=[], formatter='table', id=u'mynetwork', max_width=0, noindent=False, prefix='', request_format='json', show_details=False, variables=[]))
Next, neutronclient sends an authentication request to keystone to get a token
which is used in further operations.
.. code-block:: console
DEBUG: keystoneauth.session REQ: curl -g -i -X GET http://172.16.18.47:5000 -H "Accept: application/json" -H "User-Agent: keystoneauth1"
DEBUG: keystoneauth.session RESP: [300] Content-Length: 593 Vary: X-Auth-Token Keep-Alive: timeout=5, max=100 Server: Apache/2.4.7 (Ubuntu) Connection: Keep-Alive Date: Fri, 27 Nov 2015 20:10:54 GMT Content-Type: application/json
RESP BODY: {"versions": {"values": [{"status": "stable", "updated": "2015-03-30T00:00:00Z", "media-types": [{"base": "application/json", "type": "application/vnd.openstack.identity-v3+json"}], "id": "v3.4", "links": [{"href": "http://172.16.18.47:5000/v3/", "rel": "self"}]}, {"status": "stable", "updated": "2014-04-17T00:00:00Z", "media-types": [{"base": "application/json", "type": "application/vnd.openstack.identity-v2.0+json"}], "id": "v2.0", "links": [{"href": "http://172.16.18.47:5000/v2.0/", "rel": "self"}, {"href": "http://docs.openstack.org/", "type": "text/html", "rel": "describedby"}]}]}}
DEBUG: keystoneauth.identity.v3.base Making authentication request to http://172.16.18.47:5000/v3/auth/tokens
Neutronclient looks up a network ID corresponding to a given network name.
.. code-block:: console
DEBUG: keystoneauth.session REQ: curl -g -i -X GET http://172.16.18.47:9696/v2.0/networks.json?fields=id&name=mynetwork -H "User-Agent: python-neutronclient" -H "Accept: application/json" -H "X-Auth-Token: {SHA1}39300e7398d53a02afd183f13cb6afaef95ec4e5"
DEBUG: keystoneauth.session RESP: [200] Date: Fri, 27 Nov 2015 20:10:55 GMT Connection: keep-alive Content-Type: application/json; charset=UTF-8 Content-Length: 62 X-Openstack-Request-Id: req-ccebf6e4-4f52-4874-a1ab-5499abcba378
RESP BODY: {"networks": [{"id": "3698d3c7-d581-443e-bf86-53c4e3a738f7"}]}
Finally, neutronclient retrieves a detail of a given network using the resolved ID.
.. code-block:: console
DEBUG: keystoneauth.session REQ: curl -g -i -X GET http://172.16.18.47:9696/v2.0/networks/3698d3c7-d581-443e-bf86-53c4e3a738f7.json -H "User-Agent: python-neutronclient" -H "Accept: application/json" -H "X-Auth-Token: {SHA1}39300e7398d53a02afd183f13cb6afaef95ec4e5"
DEBUG: keystoneauth.session RESP: [200] Date: Fri, 27 Nov 2015 20:10:55 GMT Connection: keep-alive Content-Type: application/json; charset=UTF-8 Content-Length: 272 X-Openstack-Request-Id: req-261add00-d6d3-4ea7-becc-105b60ac7369
RESP BODY: {"network": {"status": "ACTIVE", "subnets": [], "name": "mynetwork", "admin_state_up": true, "tenant_id": "8f0ebf767043483a987736c8c684178d", "mtu": 0, "router:external": false, "shared": false, "port_security_enabled": true, "id": "3698d3c7-d581-443e-bf86-53c4e3a738f7"}}
+-----------------------+--------------------------------------+
| Field | Value |
+-----------------------+--------------------------------------+
| admin_state_up | True |
| id | 3698d3c7-d581-443e-bf86-53c4e3a738f7 |
| mtu | 0 |
| name | mynetwork |
| port_security_enabled | True |
| router:external | False |
| shared | False |
| status | ACTIVE |
| subnets | |
| tenant_id | 8f0ebf767043483a987736c8c684178d |
+-----------------------+--------------------------------------+

View File

@ -1,263 +0,0 @@
..
Licensed under the Apache License, Version 2.0 (the "License"); you may
not use this file except in compliance with the License. You may obtain
a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations
under the License.
Convention for heading levels in Neutron devref:
======= Heading 0 (reserved for the title in a document)
------- Heading 1
~~~~~~~ Heading 2
+++++++ Heading 3
''''''' Heading 4
(Avoid deeper levels because they do not render well.)
CLI Option Guideline
====================
This document describes the conventions of neutron CLI options.
General conventions
-------------------
#. Option names should be delimited by a hyphen instead of a underscore.
This is the common guidelines across all OpenStack CLIs.
* Good: ``--ip-version``
* Not Good: ``--ip_version``
#. Use at least one required option for ``*-create`` command. If all options
are optional, we typically use ``name`` field as a required option.
#. When you need to specify an ID of a resource, it is better to provide
another way to specify the resource like ``name`` or other reasonable field.
#. If an attribute name in API is ``foo_id``, the corresponding option
should be ``--foo`` instead of ``--foo-id``.
* It is because we usually support ID and ``name`` to specify a resource.
#. Do not use ``nargs='?'`` without a special reason.
* The behavior of ``nargs='?'`` option for python argparse is
bit tricky and may lead to unexpected option parsing different
from the help message. The detail is described in the
:ref:`Background section <background-nargs>` below.
#. (option) Avoid using positional options as much as possible.
* Positional arguments should be limited to attributes which will
be required in the long future.
#. We honor existing options and should keep compatibilities when adding or
changing options.
Options for boolean value
-------------------------
Use the form of ``--option-name {True|False}``.
* For a new option, it is recommended.
* It is suggested to use ``common.utils.add_boolean_argument`` in an
implementation. It allows ``true``/``false`` in addition to ``True``/``False``.
* For existing options, migration to the recommended form is not necessarily
required. All backward-compatibility should be kept without reasonable
reasons.
Options for dict value
----------------------
Some API attributes take a dictionary.
``--foo key1=val1,key2=val2`` is usually used.
This means ``{"key1": "val1", "key2": "val2"}`` is passed in the API layer.
Examples:
* ``--host-route destination=CIDR,nexthop=IP_ADDR`` for a subnet
* ``--fixed-ip subnet_id=SUBNET,ip_address=IP_ADDR`` for a port.
Options for list value
----------------------
Some attributes take a list.
In this case, we usually use:
* Define an option per element (Use a singular form as an option name)
* Allow to specify the option multiple times
For Example, **port-create** has ``--security-group`` option.
``--security-group SG1 --security-group SG2`` generates
``{"security_groups: ["SG1", "SG2"]}`` in the API layer.
This convention applies to a case of a list of dict.
``--allocation-pool`` and ``--host-route`` for a subnet are examples.
Compatibility with extra arguments
----------------------------------
*extra arguments* supports various types of option specifications.
At least the following patterns needs to be considered when defining
a new option. For more detail, see :ref:`cli_extra_arguments`.
* Normal options with value
* Boolean options : ``--foo True``, ``--bar=False``
* List options : ``--bars list=true val1 val2``, ``--bars val1 val2``
* Dict options : ``--foo type=dict key1=va1,key2=val2``
* List of Dict options : ``--bars list=true type=dict key1=val1,key2=val2 key3=val3,key4=val4``
* ``action=clear``
For normal options with value, there are four patterns to specify an option
as extra arguments.
* ``--admin-state-up True`` (a space between option name and value)
* ``--admin-state-up=True`` (= between option name and value)
* ``--admin_state_up True`` (underscore is used as delimiter)
* ``--admin_state_up=True`` (underscore is used as delimiter)
.. _background:
Background
----------
There are a lot of opinions on which form of options are better or not.
This section tries to capture the reason of the current choice.
Use at least one required option
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As a convention, **neutron** CLI requires one required argument.
If all options are optional in the API level and we have ``name`` field,
we usually use ``name`` as a required parameter.
Requiring at least one argument has the following benefits:
* If we run ``neutron *-create`` without a required argument, we will have a
brief help message without detail option help. It is convenient.
* We can avoid miss operation by just hitting ``neutron *-create``.
Requiring at least one parameter is a good balance.
Even though we can change this convention to allow to create a resource
without ``name`` field, it will bring confusions to existing users.
There may be opinion that it is inconsistent with API level requirement
or Horizon behavior, but even if neutron CLI requires ``name`` field
there is no bad impact on regular users. Considering possible confusion
if we change it, it looks better to keep it as-is.
Options for Boolean value
~~~~~~~~~~~~~~~~~~~~~~~~~
* ``--enable-foo``/``--disable-foo`` or similar patterns (including
``--admin-state-down``) is not suggested because we need two exclusive
options for one attribute in REST API. It is meaningless.
* It is not recommended to have an option only to specify non-default value.
For example, we have ``--shared`` or ``--admin-state-down`` options for
net-create. This form only works for ``*-create`` and does not work for
``*-update``. It leads to having different options for ``*-create`` and
``*-update``.
* A flag option like ``--enable-dhcp`` (without value) also has a problem when
considering the compatibility with *extra argument*. We can specify
``-enable-dhcp True/False`` or ``--enable-dhcp=True/False`` in the *extra
argument* mechanism. If we introduce ``--enable-dhcp`` (without value),
the form of ``-enable-dhcp True/False`` cannot be used now.
This is another reason we don't use a flag style option for a boolean parameter.
.. _background-nargs:
Avoid using nargs in positional or optional arguments
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The behavior of ``nargs='?'`` option for python argparse is bit tricky.
When we use ``nargs='?'`` and if the order of command-line options is
changed then the command-line parser may fail to parse the arguments
correctly. Two examples of such failures are provided below.
Example 1:
This example shows how the actual behavior can differ from the provided
help message. In the below block, help message at ``[5]`` says ``--bb CC``
is a valid format but the argument parsing for the same format fails at ``[7]``.
.. code-block:: console
In [1]: import argparse
In [2]: parser = argparse.ArgumentParser()
In [3]: parser.add_argument('--bb', nargs='?')
In [4]: parser.add_argument('cc')
In [5]: parser.print_help()
usage: ipython [-h] [--bb [BB]] cc
positional arguments:
cc
optional arguments:
-h, --help show this help message and exit
--bb [BB]
In [6]: parser.parse_args('--bb 1 X'.split())
Out[6]: Namespace(bb='1', cc='X')
In [7]: parser.parse_args('--bb X'.split())
usage: ipython [-h] [--bb [BB]] cc
ipython: error: too few arguments
An exception has occurred, use %tb to see the full traceback.
SystemExit: 2
Example 2:
This example shows how fragile ``nargs='?'`` can be when user specifies
options in different order from the help message.
.. code-block:: console
In [1]: import argparse
In [2]: parser = argparse.ArgumentParser()
In [3]: parser.add_argument('--a', help='option a')
In [4]: parser.add_argument('--b', help='option b')
In [5]: parser.add_argument('x', help='positional arg X')
In [6]: parser.add_argument('y', nargs='?', help='positional arg Y')
In [7]: parser.print_help()
usage: ipython [-h] [--a A] [--b B] x [y]
positional arguments:
x positional arg X
y positional arg Y
optional arguments:
-h, --help show this help message and exit
--a A option a
--b B option b
In [8]: parser.parse_args('--a 1 --b 2 X Y'.split())
Out[8]: Namespace(a='1', b='2', x='X', y='Y')
In [9]: parser.parse_args('X Y --a 1 --b 2'.split())
Out[9]: Namespace(a='1', b='2', x='X', y='Y')
In [10]: parser.parse_args('X --a 1 --b 2 Y'.split())
usage: ipython [-h] [--a A] [--b B] x [y]
ipython: error: unrecognized arguments: Y
An exception has occurred, use %tb to see the full traceback.
SystemExit: 2
To exit: use 'exit', 'quit', or Ctrl-D.
To exit: use 'exit', 'quit', or Ctrl-D.
Note: Most CLI users don't care about the order of the command-line
options. Hence, such fragile behavior should be avoided.

View File

@ -1,97 +0,0 @@
..
Licensed under the Apache License, Version 2.0 (the "License"); you may
not use this file except in compliance with the License. You may obtain
a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations
under the License.
Convention for heading levels in Neutron devref:
======= Heading 0 (reserved for the title in a document)
------- Heading 1
~~~~~~~ Heading 2
+++++++ Heading 3
''''''' Heading 4
(Avoid deeper levels because they do not render well.)
Client command extension support
=================================
The client command extension adds support for extending the neutron client while
considering ease of creation.
Extensions strongly conform to preexisting neutron commands (/neutron/v2_0/).
A sample extension can be seen at:
neutronclient/neutron/v2_0/contrib/_fox_sockets.py
Minimum requirements from an extension
--------------------------------------
* NeutronClientExtension subclasses must have a shell_command class variable
if the command is to be available to the CLI (shell.py)
Example: neutronclient.neutron.v2_0.contrib._fox_sockets.FoxInSocketsList
Minimum requirements to use canonical neutron CRUD commands framework
----------------------------------------------------------------------
Neutron commands are cliff commands, commands in extension can use their
own way to finish their tasks. But if they want to make use of the canonical
neutron CRUD commands framework, the extension should:
* have a class that subclasses NeutronClientExtension to provide the
requisite resource name, version support, and resource collection and
object paths for a resource the commands will process.
Example: neutronclient.neutron.v2_0.contrib._fox_sockets.FoxInSocket
* have a class that subclasses from the ClientExtensionList to provide
resource object list function. This is because most commands
need the list function to get object ID via
neutronclient.neutron.v2_0.__init__.find_resource_by_id.
Example: neutronclient.neutron.v2_0.contrib._fox_sockets.FoxInSocketsList
* if needed, subclass ClientExtensionUpdate to implement update of the resource
object.
Example: neutronclient.neutron.v2_0.contrib._fox_sockets.FoxInSocketsUpdate
* if needed, subclass ClientExtensionDelete to implement deletion of the resource
object.
Example: neutronclient.neutron.v2_0.contrib._fox_sockets.FoxInSocketsDelete
* if needed, subclass ClientExtensionShow to get the detail of the resource
object.
Example: neutronclient.neutron.v2_0.contrib._fox_sockets.FoxInSocketsShow
Precedence of command loading
------------------------------
* hard coded commands are loaded first
* external commands (installed in the environment) are loaded then
Commands that have the same name will be overwritten by commands that are
loaded later. To change the execution of a command for your particular
extension you only need to override the execute method.
Currently this extension support is limited to top-level resources.
Parent/child relationships may be added if desired.
neutronclient.extension entry_point
-----------------------------------
To activate the commands in a specific extension module, add an entry in
setup.cfg under neutronclient.extension. For example::
[entry_points]
neutronclient.extension =
fox_sockets = neutronclient.neutron.v2_0.contrib._fox_sockets

View File

@ -31,6 +31,4 @@ OpenStack client.
.. toctree::
:maxdepth: 2
client_command_extensions
cli_option_guideline
transition_to_osc

View File

@ -105,7 +105,7 @@ Transition Steps
In addition, no new features will be added to the CLI, though fixes to
the CLI will be assessed on a case by case basis.
8. **Not Started:** Remove the ``neutron`` CLI after two deprecation cycles
8. **Done** Remove the ``neutron`` CLI after two deprecation cycles
once the criteria below have been met.
* The networking support provide by the ``openstack`` CLI is functionally
@ -122,32 +122,8 @@ Transition Steps
Developer Guide
---------------
The ``neutron`` CLI version 6.x, without extensions, supports over 200
commands while the ``openstack`` CLI version 3.3.0 supports over 70
networking commands. Of the 70 commands, some do not have all of the options
or arguments of their ``neutron`` CLI equivalent. With this large functional
gap, a few critical questions for developers during this transition are "Which
CLI do I change?", "Where does my CLI belong?", and "Which Python library do I change?"
The answer depends on the state of a command and the state of the overall transition.
Details are outlined in the tables below. Early stages of the transition will require
dual maintenance.
**Which CLI do I change?**
+----------------------+------------------------+-------------------------------------------------+
| ``neutron`` Command | ``openstack`` Command | CLI to Change |
+======================+========================+=================================================+
| Exists | Doesn't Exist | ``neutron`` |
+----------------------+------------------------+-------------------------------------------------+
| Exists | In Progress | ``neutron`` and ``openstack`` |
| | | (update related blueprint or bug) |
+----------------------+------------------------+-------------------------------------------------+
| Exists | Exists | ``openstack`` |
| | | (assumes command parity resulting in |
| | | ``neutron`` being deprecated) |
+----------------------+------------------------+-------------------------------------------------+
| Doesn't Exist | Doesn't Exist | ``openstack`` |
+----------------------+------------------------+-------------------------------------------------+
The ``neutron`` CLI tool is now removed and all new CLI changes should be done
in the ``OpenStackClient (OSC)`` and, if needed, also in the ``OpenStack SDK``.
**Where does my CLI belong?**
@ -186,8 +162,6 @@ is not required as the neutronclient is already deprecated on its own.
+=================================================+===============================================+
| python-openstackclient | openstacksdk |
+-------------------------------------------------+-----------------------------------------------+
| python-neutronclient | python-neutronclient |
+-------------------------------------------------+-----------------------------------------------+
| Other | Applicable project owning network resource |
+-------------------------------------------------+-----------------------------------------------+

View File

@ -24,15 +24,11 @@ python-neutronclient documentation
==================================
This is a client for OpenStack Networking API. It provides
:doc:`Python API bindings <reference/index>` (the neutronclient module) and
:doc:`command-line interface (CLI) <cli/index>`.
:doc:`Python API bindings <reference/index>` (the neutronclient module).
There are two CLIs which support the Networking API:
:doc:`neutron CLI <cli/neutron>` and
There is
`OpenStack Client (OSC) <https://docs.openstack.org/python-openstackclient/latest/>`__.
OpenStack Client provides the basic network commands and
python-neutronclient provides extensions (aka OSC plugins)
for advanced networking services.
CLI which support the Networking API.
User Documentation
------------------

View File

@ -1,165 +0,0 @@
#!/bin/bash
set -x
function die() {
local exitcode=$?
set +o xtrace
echo $@
cleanup
exit $exitcode
}
net_name=mynet1
subnet_name=mysubnet1
port_name=myport1
function cleanup() {
echo Removing test port, subnet and net...
neutron port-delete $port_name
neutron subnet-delete $subnet_name
neutron net-delete $net_name
}
noauth_tenant_id=me
if [ "$1" == "noauth" ]; then
NOAUTH="--tenant_id $noauth_tenant_id"
else
NOAUTH=
fi
echo "NOTE: User should be admin in order to perform all operations."
sleep 3
# test the CRUD of network
network=$net_name
neutron net-create $NOAUTH $network || die "fail to create network $network"
temp=`neutron net-list -- --name $network --fields id | wc -l`
echo $temp
if [ $temp -ne 5 ]; then
die "networks with name $network is not unique or found"
fi
network_id=`neutron net-list -- --name $network --fields id | tail -n 2 | head -n 1 | cut -d' ' -f 2`
echo "ID of network with name $network is $network_id"
neutron net-show $network || die "fail to show network $network"
neutron net-show $network_id || die "fail to show network $network_id"
neutron net-update $network --admin_state_up False || die "fail to update network $network"
neutron net-update $network_id --admin_state_up True || die "fail to update network $network_id"
neutron net-list -c id -- --id fakeid || die "fail to list networks with column selection on empty list"
# test the CRUD of subnet
subnet=$subnet_name
cidr=10.0.1.0/24
neutron subnet-create $NOAUTH $network $cidr --name $subnet || die "fail to create subnet $subnet"
tempsubnet=`neutron subnet-list -- --name $subnet --fields id | wc -l`
echo $tempsubnet
if [ $tempsubnet -ne 5 ]; then
die "subnets with name $subnet is not unique or found"
fi
subnet_id=`neutron subnet-list -- --name $subnet --fields id | tail -n 2 | head -n 1 | cut -d' ' -f 2`
echo "ID of subnet with name $subnet is $subnet_id"
neutron subnet-show $subnet || die "fail to show subnet $subnet"
neutron subnet-show $subnet_id || die "fail to show subnet $subnet_id"
neutron subnet-update $subnet --dns_nameservers list=true 1.1.1.11 1.1.1.12 || die "fail to update subnet $subnet"
neutron subnet-update $subnet_id --dns_nameservers list=true 2.2.2.21 2.2.2.22 || die "fail to update subnet $subnet_id"
# test the crud of ports
port=$port_name
neutron port-create $NOAUTH $network --name $port || die "fail to create port $port"
tempport=`neutron port-list -- --name $port --fields id | wc -l`
echo $tempport
if [ $tempport -ne 5 ]; then
die "ports with name $port is not unique or found"
fi
port_id=`neutron port-list -- --name $port --fields id | tail -n 2 | head -n 1 | cut -d' ' -f 2`
echo "ID of port with name $port is $port_id"
neutron port-show $port || die "fail to show port $port"
neutron port-show $port_id || die "fail to show port $port_id"
neutron port-update $port --device_id deviceid1 || die "fail to update port $port"
neutron port-update $port_id --device_id deviceid2 || die "fail to update port $port_id"
neutron port-update $port_id --allowed-address-pair ip_address=1.1.1.11,mac_address=10:00:00:00:00:00 --allowed-address-pair ip_address=1.1.1.12,mac_address=10:00:00:00:00:01 || die "fail to update port $port_id --allowed-address-pair"
neutron port-show $port || die "fail to show port $port"
neutron port-show $port_id || die "fail to show port $port_id"
neutron port-update $port_id --no-allowed-address-pairs || die "fail to update port $port_id --no-allowed-address-pairs"
neutron port-show $port || die "fail to show port $port"
neutron port-show $port_id || die "fail to show port $port_id"
neutron port-delete $port_id
# test the create port with allowed-address-pairs
port=$port_name
neutron port-create $NOAUTH $network --name $port -- --allowed-address-pairs type=dict list=true ip_address=1.1.1.11,mac_address=10:00:00:00:00:00 ip_address=1.1.1.12,mac_address=10:00:00:00:00:01 || die "fail to create port $port"
tempport=`neutron port-list -- --name $port --fields id | wc -l`
echo $tempport
if [ $tempport -ne 5 ]; then
die "ports with name $port is not unique or found"
fi
port_id=`neutron port-list -- --name $port --fields id | tail -n 2 | head -n 1 | cut -d' ' -f 2`
echo "ID of port with name $port is $port_id"
neutron port-show $port || die "fail to show port $port"
neutron port-show $port_id || die "fail to show port $port_id"
neutron port-update $port_id --no-allowed-address-pairs || die "fail to update port $port_id --no-allowed-address-pairs"
neutron port-show $port_id
# test quota commands RUD
DEFAULT_NETWORKS=10
DEFAULT_PORTS=50
tenant_id=tenant_a
tenant_id_b=tenant_b
neutron quota-update --tenant_id $tenant_id --network 30 || die "fail to update quota for tenant $tenant_id"
neutron quota-update --tenant_id $tenant_id_b --network 20 || die "fail to update quota for tenant $tenant_id"
networks=`neutron quota-list -c network -c tenant_id | grep $tenant_id | awk '{print $2}'`
if [ $networks -ne 30 ]; then
die "networks quota should be 30"
fi
networks=`neutron quota-list -c network -c tenant_id | grep $tenant_id_b | awk '{print $2}'`
if [ $networks -ne 20 ]; then
die "networks quota should be 20"
fi
networks=`neutron quota-show --tenant_id $tenant_id | grep network | awk -F'|' '{print $3}'`
if [ $networks -ne 30 ]; then
die "networks quota should be 30"
fi
neutron quota-delete --tenant_id $tenant_id || die "fail to delete quota for tenant $tenant_id"
networks=`neutron quota-show --tenant_id $tenant_id | grep network | awk -F'|' '{print $3}'`
if [ $networks -ne $DEFAULT_NETWORKS ]; then
die "networks quota should be $DEFAULT_NETWORKS"
fi
# update self
if [ "t$NOAUTH" = "t" ]; then
# with auth
neutron quota-update --port 99 || die "fail to update quota for self"
ports=`neutron quota-show | grep port | awk -F'|' '{print $3}'`
if [ $ports -ne 99 ]; then
die "ports quota should be 99"
fi
ports=`neutron quota-list -c port | grep 99 | awk '{print $2}'`
if [ $ports -ne 99 ]; then
die "ports quota should be 99"
fi
neutron quota-delete || die "fail to delete quota for tenant self"
ports=`neutron quota-show | grep port | awk -F'|' '{print $3}'`
if [ $ports -ne $DEFAULT_PORTS ]; then
die "ports quota should be $DEFAULT_PORTS"
fi
else
# without auth
neutron quota-update --port 100
if [ $? -eq 0 ]; then
die "without valid context on server, quota update command should fail."
fi
neutron quota-show
if [ $? -eq 0 ]; then
die "without valid context on server, quota show command should fail."
fi
neutron quota-delete
if [ $? -eq 0 ]; then
die "without valid context on server, quota delete command should fail."
fi
neutron quota-list || die "fail to update quota for self"
fi
cleanup
echo "Success! :)"

View File

@ -1,654 +0,0 @@
# Copyright 2012 OpenStack Foundation.
# All Rights Reserved
#
# Licensed under the Apache License, Version 2.0 (the "License"); you may
# not use this file except in compliance with the License. You may obtain
# a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
# License for the specific language governing permissions and limitations
# under the License.
#
"""
Command-line interface to the Neutron APIs
"""
import argparse
import inspect
import itertools
import logging
import os
import sys
from keystoneauth1 import session
import os_client_config
from oslo_utils import encodeutils
from oslo_utils import netutils
from cliff import app
from cliff import command
from cliff import commandmanager
from neutronclient._i18n import _
from neutronclient.common import clientmanager
from neutronclient.common import exceptions as exc
from neutronclient.common import extension as client_extension
from neutronclient.neutron.v2_0 import subnet
from neutronclient.version import __version__
VERSION = '2.0'
NEUTRON_API_VERSION = '2.0'
NAMESPACE_MAP = {NEUTRON_API_VERSION: 'neutron.cli.v2'}
def run_command(cmd, cmd_parser, sub_argv):
_argv = sub_argv
index = -1
values_specs = []
if '--' in sub_argv:
index = sub_argv.index('--')
_argv = sub_argv[:index]
values_specs = sub_argv[index:]
known_args, _values_specs = cmd_parser.parse_known_args(_argv)
if(isinstance(cmd, subnet.CreateSubnet) and not known_args.cidr):
cidr = get_first_valid_cidr(_values_specs)
if cidr:
known_args.cidr = cidr
_values_specs.remove(cidr)
cmd.values_specs = (index == -1 and _values_specs or values_specs)
return cmd.run(known_args)
def get_first_valid_cidr(value_specs):
# Bug 1442771, argparse does not allow optional positional parameter
# to be separated from previous positional parameter.
# When cidr was separated from network, the value will not be able
# to be parsed into known_args, but saved to _values_specs instead.
for value in value_specs:
if netutils.is_valid_cidr(value):
return value
def env(*_vars, **kwargs):
"""Search for the first defined of possibly many env vars.
Returns the first environment variable defined in vars, or
returns the default defined in kwargs.
"""
for v in _vars:
value = os.environ.get(v, None)
if value:
return value
return kwargs.get('default', '')
def check_non_negative_int(value):
try:
value = int(value)
except ValueError:
raise argparse.ArgumentTypeError(_("invalid int value: %r") % value)
if value < 0:
raise argparse.ArgumentTypeError(_("input value %d is negative") %
value)
return value
COMMANDS = {}
# NOTE(amotoki): This is only to provide compatibility
# to existing neutron CLI extensions. See bug 1706573 for detail.
def _set_commands_dict_for_compat(apiversion, command_manager):
global COMMANDS
COMMANDS = {apiversion: dict((cmd, command_manager.find_command([cmd])[0])
for cmd in command_manager.commands)}
class BashCompletionCommand(command.Command):
"""Prints all of the commands and options for bash-completion."""
def take_action(self, parsed_args):
pass
class HelpAction(argparse.Action):
"""Print help message including sub-commands
Provide a custom action so the -h and --help options
to the main app will print a list of the commands.
The commands are determined by checking the CommandManager
instance, passed in as the "default" value for the action.
"""
def __call__(self, parser, namespace, values, option_string=None):
outputs = []
max_len = 0
app = self.default
parser.print_help(app.stdout)
app.stdout.write(_('\nCommands for API v%s:\n') % app.api_version)
command_manager = app.command_manager
for name, ep in sorted(command_manager):
factory = ep.load()
cmd = factory(self, None)
one_liner = cmd.get_description().split('\n')[0]
outputs.append((name, one_liner))
max_len = max(len(name), max_len)
for (name, one_liner) in outputs:
app.stdout.write(' %s %s\n' % (name.ljust(max_len), one_liner))
sys.exit(0)
class NeutronShell(app.App):
# verbose logging levels
WARNING_LEVEL = 0
INFO_LEVEL = 1
DEBUG_LEVEL = 2
CONSOLE_MESSAGE_FORMAT = '%(message)s'
DEBUG_MESSAGE_FORMAT = '%(levelname)s: %(name)s %(message)s'
log = logging.getLogger(__name__)
def __init__(self, apiversion):
namespace = NAMESPACE_MAP[apiversion]
description = (__doc__.strip() +
" (neutron CLI version: %s)" % __version__)
super(NeutronShell, self).__init__(
description=description,
version=VERSION,
command_manager=commandmanager.CommandManager(namespace), )
self._register_extensions(VERSION)
# Pop the 'complete' to correct the outputs of 'neutron help'.
self.command_manager.commands.pop('complete')
# This is instantiated in initialize_app() only when using
# password flow auth
self.auth_client = None
self.api_version = apiversion
_set_commands_dict_for_compat(apiversion, self.command_manager)
def build_option_parser(self, description, version):
"""Return an argparse option parser for this application.
Subclasses may override this method to extend
the parser with more global options.
:param description: full description of the application
:paramtype description: str
:param version: version number for the application
:paramtype version: str
"""
parser = argparse.ArgumentParser(
description=description,
add_help=False, )
parser.add_argument(
'--version',
action='version',
version=__version__, )
parser.add_argument(
'-v', '--verbose', '--debug',
action='count',
dest='verbose_level',
default=self.DEFAULT_VERBOSE_LEVEL,
help=_('Increase verbosity of output and show tracebacks on'
' errors. You can repeat this option.'))
parser.add_argument(
'-q', '--quiet',
action='store_const',
dest='verbose_level',
const=0,
help=_('Suppress output except warnings and errors.'))
parser.add_argument(
'-h', '--help',
action=HelpAction,
nargs=0,
default=self, # tricky
help=_("Show this help message and exit."))
parser.add_argument(
'-r', '--retries',
metavar="NUM",
type=check_non_negative_int,
default=0,
help=_("How many times the request to the Neutron server should "
"be retried if it fails. Defaults to 0."))
# FIXME(bklei): this method should come from keystoneauth1
self._append_global_identity_args(parser)
return parser
def _append_global_identity_args(self, parser):
# FIXME(bklei): these are global identity (Keystone) arguments which
# should be consistent and shared by all service clients. Therefore,
# they should be provided by keystoneauth1. We will need to
# refactor this code once this functionality is available in
# keystoneauth1.
#
# Note: At that time we'll need to decide if we can just abandon
# the deprecated args (--service-type and --endpoint-type).
parser.add_argument(
'--os-service-type', metavar='<os-service-type>',
default=env('OS_NETWORK_SERVICE_TYPE', default='network'),
help=_('Defaults to env[OS_NETWORK_SERVICE_TYPE] or "network".'))
parser.add_argument(
'--os-endpoint-type', metavar='<os-endpoint-type>',
default=env('OS_ENDPOINT_TYPE', default='public'),
help=_('Defaults to env[OS_ENDPOINT_TYPE] or "public".'))
# FIXME(bklei): --service-type is deprecated but kept in for
# backward compatibility.
parser.add_argument(
'--service-type', metavar='<service-type>',
default=env('OS_NETWORK_SERVICE_TYPE', default='network'),
help=_('DEPRECATED! Use --os-service-type.'))
# FIXME(bklei): --endpoint-type is deprecated but kept in for
# backward compatibility.
parser.add_argument(
'--endpoint-type', metavar='<endpoint-type>',
default=env('OS_ENDPOINT_TYPE', default='public'),
help=_('DEPRECATED! Use --os-endpoint-type.'))
parser.add_argument(
'--os-auth-strategy', metavar='<auth-strategy>',
default=env('OS_AUTH_STRATEGY', default='keystone'),
help=_('DEPRECATED! Only keystone is supported.'))
parser.add_argument(
'--os_auth_strategy',
help=argparse.SUPPRESS)
parser.add_argument(
'--os-cloud', metavar='<cloud>',
help=_('Defaults to env[OS_CLOUD].'))
parser.add_argument(
'--os-auth-url', metavar='<auth-url>',
help=_('Authentication URL, defaults to env[OS_AUTH_URL].'))
parser.add_argument(
'--os_auth_url',
help=argparse.SUPPRESS)
project_name_group = parser.add_mutually_exclusive_group()
project_name_group.add_argument(
'--os-tenant-name', metavar='<auth-tenant-name>',
help=_('Authentication tenant name, defaults to '
'env[OS_TENANT_NAME].'))
project_name_group.add_argument(
'--os-project-name',
metavar='<auth-project-name>',
help=_('Another way to specify tenant name. '
'This option is mutually exclusive with '
' --os-tenant-name. '
'Defaults to env[OS_PROJECT_NAME].'))
parser.add_argument(
'--os_tenant_name',
help=argparse.SUPPRESS)
project_id_group = parser.add_mutually_exclusive_group()
project_id_group.add_argument(
'--os-tenant-id', metavar='<auth-tenant-id>',
help=_('Authentication tenant ID, defaults to '
'env[OS_TENANT_ID].'))
project_id_group.add_argument(
'--os-project-id',
metavar='<auth-project-id>',
help=_('Another way to specify tenant ID. '
'This option is mutually exclusive with '
' --os-tenant-id. '
'Defaults to env[OS_PROJECT_ID].'))
parser.add_argument(
'--os-username', metavar='<auth-username>',
help=_('Authentication username, defaults to env[OS_USERNAME].'))
parser.add_argument(
'--os_username',
help=argparse.SUPPRESS)
parser.add_argument(
'--os-user-id', metavar='<auth-user-id>',
help=_('Authentication user ID (Env: OS_USER_ID)'))
parser.add_argument(
'--os_user_id',
help=argparse.SUPPRESS)
parser.add_argument(
'--os-user-domain-id',
metavar='<auth-user-domain-id>',
help=_('OpenStack user domain ID. '
'Defaults to env[OS_USER_DOMAIN_ID].'))
parser.add_argument(
'--os_user_domain_id',
help=argparse.SUPPRESS)
parser.add_argument(
'--os-user-domain-name',
metavar='<auth-user-domain-name>',
help=_('OpenStack user domain name. '
'Defaults to env[OS_USER_DOMAIN_NAME].'))
parser.add_argument(
'--os_user_domain_name',
help=argparse.SUPPRESS)
parser.add_argument(
'--os_project_id',
help=argparse.SUPPRESS)
parser.add_argument(
'--os_project_name',
help=argparse.SUPPRESS)
parser.add_argument(
'--os-project-domain-id',
metavar='<auth-project-domain-id>',
help=_('Defaults to env[OS_PROJECT_DOMAIN_ID].'))
parser.add_argument(
'--os-project-domain-name',
metavar='<auth-project-domain-name>',
help=_('Defaults to env[OS_PROJECT_DOMAIN_NAME].'))
parser.add_argument(
'--os-cert',
metavar='<certificate>',
help=_("Path of certificate file to use in SSL "
"connection. This file can optionally be "
"prepended with the private key. Defaults "
"to env[OS_CERT]."))
parser.add_argument(
'--os-cacert',
metavar='<ca-certificate>',
help=_("Specify a CA bundle file to use in "
"verifying a TLS (https) server certificate. "
"Defaults to env[OS_CACERT]."))
parser.add_argument(
'--os-key',
metavar='<key>',
help=_("Path of client key to use in SSL "
"connection. This option is not necessary "
"if your key is prepended to your certificate "
"file. Defaults to env[OS_KEY]."))
parser.add_argument(
'--os-password', metavar='<auth-password>',
help=_('Authentication password, defaults to env[OS_PASSWORD].'))
parser.add_argument(
'--os_password',
help=argparse.SUPPRESS)
parser.add_argument(
'--os-region-name', metavar='<auth-region-name>',
help=_('Authentica