The patch https://review.opendev.org/#/c/673389/ introduced a regression
by changing the osc-lib interface.

Two conflicting attempts to fix the regression were launched:

1) Reverting the patch.

2) The patch https://review.opendev.org/683119 changes the exception
   from the generic CommandError back to a specific Forbidden exception.

   The patch https://review.opendev.org/683118 catches this exception
   and passes on, i.e. re-implements the same behavior as before.

The first idea was implemented, the initial patch reverted. The second
idea was partially implemented. The change in python-openstackclient
(683118) was merged. The change in osc-lib was approved but failed to
merge because the initial change had been reverted.

Now we have again a situation where the exception produced in osc-lib
does not match the exception expected by the caller.

It is unclear if the osc-lib interface will ever get a rebased version
of https://review.opendev.org/683119 merged, so the safest way to
address the issue is to also catch the exception that used to be
thrown before the inital change and is again thrown after the inital
change has been reverted.

Change-Id: I2ea2def607ec5be112e42d53a1e660fef0cdd69c
(cherry picked from commit 0a8753dc3eaeda25554ccd769350de1e9792a62b)

$namespace = openstack.network.v2

The subcommand documents for $namespace were hardcoded and thus prone to
drift over time. This commit removes the hardcoded content and uses the
autoprogram-cliff directive to generate them automatically from the
subcommand configuration classes.

This one turned out to be quite involved, because we support both
neutron and nova-network. When running in a real cloud, the command
classes detect whether the neutron service is present, assume
nova-network if that service is not found, and only add parser options
relevant to the detected service. But the docs need to present both sets
of options. This was easy enough when they were hardcoded, but required
a bit of additional infrastructure for generated docs.

Change-Id: I426261eb1d86bcc68656aabd61f10b7f082da402

The patch https://review.opendev.org/#/c/673389/
introduced a regression by changing the osc-lib
interface.

The patch
https://review.opendev.org/683119
changes the exception from the generic CommandError
back to a specific Forbidden exception.

This patch catches this exception and passes on, i.e.
re-implements the same behavior as before.

Story: 2006547

Change-Id: I17b1ec7abaa5b0828ccbcad40bd928565c5c59fb
Signed-off-by: Andreas Florath <Andreas.Florath@telekom.de>

When user passes --region None, the find_resource
of osc_lib calls get() of region. The get API of
region ignores the name param returning all the
regions in result. As the find_resource checks
many cases against the result returned by get API.
The output comes greater than 1, thus returning
"More than one region ID exist" which is incorrect.
However in case of region which cannot be filtered
by name we do not require to check these many cases.

The solution is to directly call the get method of
APIs and returning No resource name exist with the
xyz" on passing invaid parameter. And returning all
in case of None.

Thus created a new function get_resource which can
be used in future too by these types of API's.

Change-Id: Ib3f881d34a82af97199ce51bfbefc6f3f08599f1
Closes-bug: #1799153

Add support for creating, retrieving, and deleting application
credentials. Application credentials do not support updates.

In order to provide a positive user experience for the `--role` option,
this patch also includes an improvement to the
`identity.common._get_token_resource()` function that allows it to
introspect the roles list within a token. This way there is no need to
make a request to keystone to retrieve a role object, which would fail
most of the time anyway due to keystone's default policy prohibiting
unprivileged users from retrieving roles.

bp application-credentials

Change-Id: I29e03b72acd931305cbdac5a9ff666854d05c6d7

Currently ListEndpoint.take_action method unconditionally iterates
over all endpoints and issue GET /v3/services/<ep.service_id>
request for each endpoint. In case of HTTPS keystone endpoint this
can take significant amout of time, and it only getting worse in
case of multiple regions.

This commit change this logic to making just two GET requests: first
it gets endpoint list, then it gets service list, searching service
in the list instead of issuing GET /v3/services/<id> request.

Change-Id: I22b61c0b45b0205a2f5a4608c2473cb7814fe3cf
Closes-Bug: 1719413

The 'domain' filter not work well in commands 'project show',
'user show' and 'user set'.

Depends-On: I490900d6249f01654d4cba43bddd3e7af7928a84
Closes-Bug: #1704097
Change-Id: Ib4f47cbaba27eb56c4a41d187fee74a995e62dc7

A role entity can now be specified as domain specific.

Closes-bug: #1606105
Change-Id: I564cf3da1d61f5bfcf85be591480d2f5c8d694a0

if there are more than one services be found with one
name, a NoUniqueMatch exception should be raised but
we can see a NotFound Exception raised instead. It is
because in "find_service()", we use "find_resource()"
first, if "find_resource()" return a exception, we just
think it is a NotFound Exception and continue to find
by type but ignore a NoUniqueMatch exception of
"find_resource()". This patch refactor the "find_service()"
method to solve this problem.

Change-Id: Id4619092c57f276ae0698c89df0d5503b7423a4e
Co-Authored-By: Huanxuan Ao <huanxuan.ao@easystack.cn>
Closes-Bug:#1597296

Currently a user is allowed to specify either a resource ID or name
when running openstack identity comands. In some cases, when a name
is specified instead of an ID, the command will return as not able
to find the resource when it in fact does exist.

The changes here are to check the client against the token on such
requests and to extract the ID of the resource specified if enough
information exists between the two. We then use the ID associated
with the resource to complete the user requests.

Change-Id: I40713b0ded42063b786dc21247e854224b9d2fe2
Closes-Bug: #1561599