Keystone let's users remove role assignments that reference non-existent
users and groups. This is nice when keystone backs to an identity store
like LDAP and users or groups are removed.

Previously, openstackclient would validate the user and group existed in
keystone before sending the request to delete the role assignment. This
commit updates the code to bypass that validation so that users can use
IDs to forcibly cleanup role assignments.

Change-Id: I102b41677736bbe37a82abaa3c5b3e1faf2475d5
Story: 2006635
Task: 36848
(cherry picked from commit e24673267093de85beee753860cda1fb224ce4bc)

When we use "--property" parameter, client get lists these the
value is string type, but the type of the value 'is_domain'
should be boolean, so we should judge it and parse it.
The patch parse string to boolean for value 'is_domain'.

Co-Authored-By: Lance Bragstad <lbragstad@gmail.com>

Conflict:
  Direct backports of this patch fail because the original tests
  proposed to the Victoria (master) branch included keystone
  ``options``. Support for ``options`` was added in:

    I9c3bdd741f28bf558267fb217818d947597ce13e

  This backport removes the ``options`` key from the expected values in
  the tests since feature support for ``options`` isn't going to be
  backported. Otherwise, the functionality of this change is fully
  tested like it is on later releases.

Change-Id: I37c9eb854524bde3a1530bfe2e3a03810fb1a676
Task: 30039
Story: 2005246
(cherry picked from commit 533af9f1b2de40d98f69e83cdf89ecf254cf3879)
(cherry picked from commit 19723aee18e2901e9250dd840a61359704baa170)

Partial-Bug: #1687955
Partially implement blueprint osc-formattable-columns

Change-Id: Ia13314a012b3a7363ffb24a13c79c6ecdff1ed7b

The following were deprecated over two years ago and can now be
removed/changed:

* Remove ``service create`` option ``--type``
* Remove ``role list`` options ``--project`` and ``--user``
* Remove ``user role list`` command

These are backwards incompatible changes and will require a major
version bump after they are merged.

Change-Id: I29e2fc9516dffbfd83eef0bc91e834dde99b4105
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Signed-off-by: Dean Troyer <dtroyer@gmail.com>

There is a typo in the endpoint group deletion, due to this you
can't remove endpoint groups once assigned. I am adding also the
unit tests to avoid this kind of issues in the future

Task: 30640
Story: 2005521
Change-Id: Ie938f2c9894bb39b4c0ed1f7aa3a6a751a303058

Regsitered limit set CLI takes --service, --region and
--resource-name as param which can be updated along with
--default limit for existing registered limit.

Default limit can be updated with same value and CLI
return the success. But --service, --region and --resource-
name cannot be same as existing one. CLI return 409
for this case. Which is valid behaviour because more than
one limit with same service and same resource cannot exist.

But help message of --service, --region and --resource-name
are not much clear to tell that they cannot be passed with
same value.

This patch clarifies the help message for resigtered limit set CLI.

Reference Scenario:
*  openstack registered limit set --default-limit 91 64c2e97fbe904b888544ffdcab21989b
limit updated sucessfully

Updating limit with exsiting service and resource-name:

* openstack registered limit set --default-limit 92 --resource-name snapshot 64c2e97fbe904b888544ffdcab21989b
Conflict occurred attempting to store registered_limit - Duplicate entry. (HTTP 409)

*openstack registered limit set --default-limit 93 --service compute 64c2e97fbe904b888544ffdcab21989b
Conflict occurred attempting to store registered_limit - Duplicate entry. (HTTP 409)

*openstack registered limit set --default-limit 91 --resource-name snapshot --service glance 64c2e97fbe904b888544ffdcab21989b
Conflict occurred attempting to store registered_limit - Duplicate entry. (HTTP 409)

Change-Id: I9e78a6250567cd981adde96946818bb016760a49

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