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
This patch adds the --immutable and --no-immutable option to the
role, project and domain CLI.
Related-Patch: https://review.opendev.org/#/c/712182/
Change-Id: I9c3bdd741f28bf558267fb217818d947597ce13e
$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
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
Use osc-lib directly for exceptions.
Leave openstackclient.common.exceptions for deprecation period.
Change-Id: Iea3e862302372e1b31ccd27f69db59b4953ca828
Once inherited project role grant calls are
implemented on python-keystoneclient,
python-openstackclient also should support such
calls.
This patch add such support as well as its
related tests.
Co-Authored-By: Raildo Mascena <raildo@lsd.ufcg.edu.br>
Change-Id: Id72670be8640e5c6e2490a6ef849e9ec3493b1a9
Implements: blueprint hierarchical-multitenancy
Many of the commands for the group and role resources were lacking an
option to specify the specific domain groups, projects or users belong
to. This commit fixes that.
Change-Id: I461d2bcfd01ad2dea970de38ec7ad6f4a631ceb1
Closes-bug: #1446546
If users, projects or groups are provided by name, there is a
possibility of the existence other users/projects/groups with the same
name in other domain. Even though this is not a problem if the actual
ID is given instead of a name; this is mostly a usability enhancement.
So, three options were added, one for specifying the domain where the
user belongs, another one to specify the project's domain, and finally
one to specify the group's domain.
Change-Id: Iab04b0e04fa75ea5aa3723b8ea42a45f58a6cdb2
Closes-Bug: #1421328
Based on the comments made in this patch:
https://review.openstack.org/#/c/174908/2/
We should simplify and refactor the way we handle finding identity
resources.
Change-Id: I77db2e3564faa90a917082a6c6cb87269e93aebe
When using Keystone's policy.v3cloudsample.json policy file, a project admin is
supposed to be able to manage role assignments. Unfortunately, a project admin
isn't allowed to perform these operations using python-openstackclient, as we
attempt to perform list operations for any of the object types specified (users,
groups, projects). This is done in an attempt to lookup the id of the object by
name, but we perform this list operation even when the user specifies everything
by id. This causes 403 errors.
This patch still attempts to look up the object id by name, but we catch the 403
and assume that the user specified an id if the list operation is not allowed.
This is similar to what we do with the --domain option for other commands.
Closes-bug: #1445528
Change-Id: Id95a8520e935c1092d5a22ecd8ea01f572334ac8
This should make it easier to understand the
purpose of find_domain - I believe the reason
for which find_resource wasn't enough was not
quite clear.
Change-Id: I6a1cdfa86f52401d95c6da2cd38d7c95a140b4a1
Domain administrator cannot do project operations because the
require access to the domain API (which they don't have). When
attempting to find a domain for project operations, ignore errors
because the API returns nothing without indicating there is a
problem. The domain administrators will have to use a domain id,
but they will still be able to do project operations. If the user
does not have permission to read the domain table, they cannot
use domain names.
Change-Id: Ieed5d420022a407c8296a0bb3569d9469c89d752
Closes-Bug: #1317478
Closes-Bug: #1317485
Make endpoints more consistent across create, show, etc
* Make the name option required for create
* Use a common function to fetch services by id, name or type
* Have show work by endpoint id or by service id, type or name
* Have show display all the fields by default
* Remove capability to filter queries by attribute value pairs
Change-Id: Idaa4b8d930ba859fd62de777e44a10b1ed58c79b
Partial-Bug: #1184012
