Using OpenStack from CLI is currently different for each project. Let's fix that!
Originally started as a bug. This page addresses how openstack users will interact with glance/nova (and other) CLI tools for the ESSEX release.
This will be absorbed into UnifiedCLI as that gets developed.
- examples are for environment variables, should cover library api as well?
- standardize method for generating a token / getting endpoint list (keystone client?)
- integration with swift client?
State of Diablo
To configure python-novaclient you use environment variables:
NOVA_URL=http://example.com:5000/v2.0/ NOVA_VERSION=1.1 NOVA_USERNAME=openstack NOVA_API_KEY=yadayada NOVA_PROJECT_ID=myproject
Whereas to configure glance we set:
OS_AUTH_USER=<YOUR USERNAME> OS_AUTH_KEY=<YOUR API KEY> OS_AUTH_TENANT=<YOUR TENANT ID> OS_AUTH_URL=<THIS SHOULD POINT TO KEYSTONE> OS_AUTH_STRATEGY=keystone
Glance also provides a script tools/nova_to_os_env.sh which helps convert these nova users interact with glance.
Thus, at this time there are multiple and competing techniques for auth being used in OS projects. For essex, a consistent and unified strategy should be designed and implemented across the CLIs.
And to configure Swift we set:
ST_AUTH=<auth token URL> # --auth ST_USER=<username> # --user ST_KEY=<auth key> # --key
Support two flows:
- PASSWORD FLOW: User can either specify ids/names/passwords and the CLI will communicate with keystone to get a token
- TOKEN FLOW: User can specify the token (having already been through the keystone dance to retrieve it)
The password flow is useful when the client have to do many calls (in a scripted fashion) or also when used via an API.
Both glance and nova cli would update their code & docs to reflect the new env variables - but would continue supporting during ESSEX their deprecated variables. (pulling from them if new-style variables aren't set)
- require specification of user id or name
- for essex keystone will support default tenant, a client can override the default tenant by specifying it
- require keystone endpoint
require: OS_AUTH_URL=<THIS SHOULD POINT TO KEYSTONE> # --os_auth_url OS_PASSWORD=<YOUR PASSWORD> # --os_password OS_USERNAME=<YOUR USER NAME> # --os_username # allow one of the following: OS_TENANT_ID=<YOUR TENANT ID> # --os_tenant_id OS_TENANT_NAME=<YOUR TENANT NAME> # --os_tenant_name
- IDs vs NAMEs in Keystone: While both ids and names are meant to be unique, IDs are immutable whereas the name can change
- tenant is required until default tenants / unscoped tokens / ... is further defined in keystone
If a client is going to make multiple calls, caching it locally is more efficient for both the user and service. (See discussion in glance bug)
OS_AUTH_URL=<THIS SHOULD POINT TO KEYSTONE> # --os_auth_url OS_TOKEN=<YOUR TOKEN> # --os_token
- If user sets variables for both password and token flows, the token should take preference
- perhaps this flow only works if you also know the endpoint of the glance/nova service (eg, you need to supply both the token & endpont)
Some clients have additional variables to control authentication behaviour. Where they exist these should follow the same convention.
OS_REGION_NAME=<region> # Glance OS_AUTH_STRATEGY=noauth|keystone # Glance
Setting parameters via flag
Any environment variable parameter can alternatively be specified via flag. This flag should be the same as a downcase version of the environment variable. For example: OS_AUTH_URL can be specified with the --os_auth_url flag. This will hopefully lessen confusion between the values used for authentication and the values that a given command might require, e.g. creating a user in Keystone required both an authentication username as well as the name of the user to be created.
Python implementations should internally use names that are similar to CLI variables, so that all projects refer to these concepts in the same way. For example:
- os_username # or os_user.id
- os_tenant_id # or os_tenant.id
- os_tenant_name # or os_tenant.name