If you use the former, you get a pretty error message when there's a
failure. If you use the latter, you get an ugly traceback when used with
the '--debug' flag.
Without this change:
$ openstack flavor create ... --property '' foo
...
Traceback (most recent call last):
File "/tmp/venv/lib/python3.11/site-packages/cliff/app.py", line 402, in run_subcommand
parsed_args = cmd_parser.parse_args(sub_argv)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.11/argparse.py", line 1862, in parse_args
args, argv = self.parse_known_args(args, namespace)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.11/argparse.py", line 1895, in parse_known_args
namespace, args = self._parse_known_args(args, namespace)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.11/argparse.py", line 2107, in _parse_known_args
start_index = consume_optional(start_index)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.11/argparse.py", line 2047, in consume_optional
take_action(action, args, option_string)
File "/usr/lib64/python3.11/argparse.py", line 1971, in take_action
action(self, namespace, argument_values, option_string)
File "/tmp/venv/lib/python3.11/site-packages/osc_lib/cli/parseractions.py", line 45, in __call__
raise argparse.ArgumentTypeError(msg % str(values))
argparse.ArgumentTypeError: Expected 'key=value' type, but got:
clean_up CreateFlavor: Expected 'key=value' type, but got:
With this change:
$ openstack flavor create ... --property '' foo
...
usage: openstack flavor create [-h] [-f {json,shell,table,value,yaml}] [-c COLUMN]
[--noindent] [--prefix PREFIX] [--max-width <integer>]
[--fit-width] [--print-empty] [--id <id>]
[--ram <size-mb>] [--disk <size-gb>]
[--ephemeral <size-gb>] [--swap <size-mb>]
[--vcpus <vcpus>] [--rxtx-factor <factor>]
[--public | --private] [--property <key=value>]
[--project <project>] [--description <description>]
[--project-domain <project-domain>]
<flavor-name>
openstack flavor create: error: argument --property: Expected 'key=value' type, but got:
clean_up CreateFlavor:
Change-Id: I9e78b35ad9d016d7a33655141ec579397c5344c0
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Team and repository tags
OpenStackClient
OpenStackClient (aka OSC) is a command-line client for OpenStack that brings the command set for Compute, Identity, Image, Network, Object Store and Block Storage APIs together in a single shell with a uniform command structure.
The primary goal is to provide a unified shell command structure and a common language to describe operations in OpenStack.
- PyPi - package installation
- Online Documentation
- Launchpad project - bugs and feature requests
- Blueprints - feature specifications (historical only)
- Source
- Developer - getting started as a developer
- Contributing - contributing code
- Testing - testing code
- IRC: #openstack-sdks on OFTC (irc.oftc.net)
- License: Apache 2.0
Getting Started
OpenStack Client can be installed from PyPI using pip:
pip install python-openstackclient
There are a few variants on getting help. A list of global options
and supported commands is shown with --help:
openstack --help
There is also a help command that can be used to get
help text for a specific command:
openstack help
openstack help server create
If you want to make changes to the OpenStackClient for testing and contribution, make any changes and then run:
python setup.py develop
or:
pip install -e .
Configuration
The CLI is configured via environment variables and command-line options as listed in https://docs.openstack.org/python-openstackclient/latest/cli/authentication.html.
Authentication using username/password is most commonly used:
For a local user, your configuration will look like the one below:
export OS_AUTH_URL=<url-to-openstack-identity> export OS_IDENTITY_API_VERSION=3 export OS_PROJECT_NAME=<project-name> export OS_PROJECT_DOMAIN_NAME=<project-domain-name> export OS_USERNAME=<username> export OS_USER_DOMAIN_NAME=<user-domain-name> export OS_PASSWORD=<password> # (optional)The corresponding command-line options look very similar:
--os-auth-url <url> --os-identity-api-version 3 --os-project-name <project-name> --os-project-domain-name <project-domain-name> --os-username <username> --os-user-domain-name <user-domain-name> [--os-password <password>]For a federated user, your configuration will look the so:
export OS_PROJECT_NAME=<project-name> export OS_PROJECT_DOMAIN_NAME=<project-domain-name> export OS_AUTH_URL=<url-to-openstack-identity> export OS_IDENTITY_API_VERSION=3 export OS_AUTH_PLUGIN=openid export OS_AUTH_TYPE=v3oidcpassword export OS_USERNAME=<username-in-idp> export OS_PASSWORD=<password-in-idp> export OS_IDENTITY_PROVIDER=<the-desired-idp-in-keystone> export OS_CLIENT_ID=<the-client-id-configured-in-the-idp> export OS_CLIENT_SECRET=<the-client-secred-configured-in-the-idp> export OS_OPENID_SCOPE=<the-scopes-of-desired-attributes-to-claim-from-idp> export OS_PROTOCOL=<the-protocol-used-in-the-apache2-oidc-proxy> export OS_ACCESS_TOKEN_TYPE=<the-access-token-type-used-by-your-idp> export OS_DISCOVERY_ENDPOINT=<the-well-known-endpoint-of-the-idp>The corresponding command-line options look very similar:
--os-project-name <project-name> --os-project-domain-name <project-domain-name> --os-auth-url <url-to-openstack-identity> --os-identity-api-version 3 --os-auth-plugin openid --os-auth-type v3oidcpassword --os-username <username-in-idp> --os-password <password-in-idp> --os-identity-provider <the-desired-idp-in-keystone> --os-client-id <the-client-id-configured-in-the-idp> --os-client-secret <the-client-secred-configured-in-the-idp> --os-openid-scope <the-scopes-of-desired-attributes-to-claim-from-idp> --os-protocol <the-protocol-used-in-the-apache2-oidc-proxy> --os-access-token-type <the-access-token-type-used-by-your-idp> --os-discovery-endpoint <the-well-known-endpoint-of-the-idp>
If a password is not provided above (in plaintext), you will be interactively prompted to provide one securely.