IssueToken.take_action() was missed in updating the structure of
the ClientManager.
Also, TOKEN_WITH_TENANT_ID in v3 is just wrong...
Closes-Bug: #1383396
Change-Id: If2dd82a26af1d743ee9df73e0c1aebce497bf22e
Currently, we repeated to generate clientmanager instance when run
command in interactive mode. This should be avoided.
Change-Id: I0536a690bc173be38af08a2e4443115532041efd
Closes-Bug: #1383083
Anything that needs a service catalog can get it directly from
auth_ref.service_catalog, no need to carry the extra attribute.
ClientManager.get_endpoint_for_service_type() reamins the proper
method to get an endpoint for clients that still need one directly.
Change-Id: I809091c9c71d08f29606d7fd8b500898ff2cb8ae
Clients that can use ksc Session don't need the old junk to
fake auth anymore:
* compute
* volume
Clients that still need to be fed credentials can pick directly
from the auth object in clientmanager. The _token attribute is
removed, the token can be retrieved from the auth object:
openstackclient/tests/common/test_clientmanager.py
This change will break any plugin that relies on getting a token
from instance._token. They should be updated to use the above, or
preferable, to use keystoneclient.session.Session to create its
HTTP interface object.
Change-Id: I877a29de97a42f85f12a14c274fc003e6fba5135
keystoneclient/openstack/common/jsonutils.py is removed in this patch
https://review.openstack.org/#/c/128454/
Now, we should use jsonutils in oslo.serialization package.
Change-Id: I7c8e8e6d5dffa85244368fd578616c9b19f4fd21
The OSC plugins work by adding an object as an attribute to a
ClientManager instance. The initialization and management of
thos plugins belongs in clientmanager.py.
At this point the only part not moved is the API version dict
initialization bcause the timing and connection to the
CommandManager initialization. It gets refactored anyway when
API discovery becomes operational.
Change-Id: If9cb9a0c45a3a577082a5cdbb793769211f20ebb
The ksc auth plugins do not have support for the original
token-endpoint (aka token flow) auth where the user supplies
a token (possibly the Keystone admin_token) and an API endpoint.
This is used for bootstrapping Keystone but also has other uses
when a scoped user token is provided.
The api.auth:TokenEndpoint class is required to provide the
same interface methods so all of the special-case code branches
to support token-endpoint can be removed.
Some additional cleanups related to ClientManager and creating
the Compute client also were done to streamline using sessions.
Change-Id: I1a6059afa845a591eff92567ca346c09010a93af
The links field in the returned objects from the v3 Identity
API aren't really useful, so let's remove them.
Managed to remove most of them from the core API.
I'll likely remove the extension/contribution (oauth/federation)
related ones in another patch.
Also in this patch the code for setting services and projects
was changed. Though not incorrect, it was not needed to copy
the entire returned object, we should just need to pass in
the fields we want to update.
Change-Id: I164ca9ad8b28fa10b291e9115ef40753e387c547
Currently the code is broken as it references a part of
keystoneclient that does not exist.
Change-Id: I7fbc754537fbb4acffb166b5854840acfaef1fb8
Closes-Bug: #1379871
In a cloud with AZs, you can get multiple entries back from the service
catalog - one for each AZ and then one that is AZ agnostic that's tied
to the region. If the region_name is plumbed all the way through, this
works as intended.
Change-Id: I3b365ea306e8111fc80830672ae8080a5d1dc8e0
Performing create, list, or set operations for users, groups, and projects
with the --domain option attempts to look up the domain for name to ID
conversion. In the case of an environment using Keystone domains, it is
desired to allow a domain admin to perform these operations for objects in
their domain without allowing them to list or show domains. The current
behavior prevents the domain admin from performing these operations since
they will be forbidden to perform the underlying list_domains operation.
This patch makes the domain lookup error a soft failure, and falls back
to using the passed in domain argument directly as a domain ID in the
request that it sends to Keystone.
Change-Id: I5139097f8cedc53693f6f71297518917ac72e50a
Closes-Bug: #1378565
Update `user show` for Identity V3 to account for a domain argument,
in doing so, also update `find resource` to be more flexible by
allowing **kwargs.
Also update `group show` and `project show` since they follow the
same logic as a user within a group.
Change-Id: Ib828e4dbeb0bd31164396069ce8a64c873179779
Closes-Bug: #1378165
This patch allows the user to choose which authentication plugin
to use with the CLI. The arguments needed by the auth plugins are
automatically added to the argument parser. Some examples with
the currently available authentication plugins::
OS_USERNAME=admin OS_PROJECT_NAME=admin OS_AUTH_URL=http://keystone:5000/v2.0 \
OS_PASSWORD=admin openstack user list
OS_USERNAME=admin OS_PROJECT_DOMAIN_NAME=default OS_USER_DOMAIN_NAME=default \
OS_PROJECT_NAME=admin OS_AUTH_URL=http://keystone:5000/v3 OS_PASSWORD=admin \
OS_IDENTITY_API_VERSION=3 OS_AUTH_PLUGIN=v3password openstack project list
OS_TOKEN=1234 OS_URL=http://service_url:35357/v2.0 \
OS_IDENTITY_API_VERSION=2.0 openstack user list
The --os-auth-plugin option can be omitted; if so the CLI will attempt to
guess which plugin to use from the other options.
Change-Id: I330c20ddb8d96b3a4287c68b57c36c4a0f869669
Co-Authored-By: Florent Flament <florent.flament-ext@cloudwatt.com>
* Add method to CommandManager to retrieve command names by group
* Add ListCommands
To list command groups loaded by cliff
Change-Id: I37fe2471aa2fafa8aa223159452d52b1981021d6
Openstackclient needs to have a capability to manage federated protocols
(like saml2, openid connect, abfab). This patch allows users to
administrate such operations from the commandline.
Change-Id: I59eef2acdda60c7ec795d1bfe31e8e960b4478a1
Implements: bp/add-openstackclient-federation-crud
Cliff 1.6.1 added CommandManager.load_commands() so we can adopt it
rather than rolling our own.
Also, that second group is Greek, not Latin. Jeez...
Change-Id: I4a63c22f37bcfd0ef5d83c2dbd08b58fda0db35c
1) Can't create instance of swiftclient. Since we now create
an API instance, creating a swiftclient instance won't work.
Trying to do any object related command fails.
2) Listing objects in a container fails, we depend on the
data returned in a specific way, during the API transition
this must have slipped through.
Needs regression/funcitonal tests to mame sure this doesn't
happen again.
Change-Id: I69079a0dc9f32b84e6f9307729d3dbbba549ac5e
