Domains should be supported for 'user show' command

Bug #1378165 reported by Nathan Kinder
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
python-openstackclient
Fix Released
Undecided
Nathan Kinder

Bug Description

When using Keystone domains, it is possible to list users for a specific domain in python-openstackclient by specifying the '--domain' option as so:

(openstack) user list
+----------------------------------+-------------+
| ID | Name |
+----------------------------------+-------------+
| 21e38d0643fb48b4aef9480a9dc07ff6 | cloud_admin |
+----------------------------------+-------------+
(openstack) user list --domain ipa
+------------------------------------------------------------------+----------+
| ID | Name |
+------------------------------------------------------------------+----------+
| a089b38b1406171f5473035de7075bcf6efabe5666ccb330ee5224b81f084506 | admin |
| d6375cc35e259365bb3f22a9571557c2ac845507a25b112a73663cc04c7ef897 | keystone |
+------------------------------------------------------------------+----------+

Unfortunately, it is not possible to show a user from a different domain, as the '--domain' option is not valid for the 'user show' command:

-----------------------------------------------------------------------
(openstack) user show --domain ipa admin
usage: user show [-h] [-f {shell,table,value}] [-c COLUMN]
                 [--max-width <integer>] [--prefix PREFIX]
                 <user>
user show: error: unrecognized arguments: --domain admin
-----------------------------------------------------------------------

The '--domain' option should be supported for the 'user-show' command.

Nathan Kinder (nkinder)
Changed in python-openstackclient:
assignee: nobody → Nathan Kinder (nkinder)
status: New → In Progress
Revision history for this message
Nathan Kinder (nkinder) wrote :

This looks like it will require changes to python-keystoneclient, as UserManager.get() currently only accepts a single 'user' argument:

---------------------------------------------------
      def get(self, user):
        return super(UserManager, self).get(
            user_id=base.getid(user))
---------------------------------------------------

Revision history for this message
Steve Martinelli (stevemar) wrote :
Revision history for this message
Steve Martinelli (stevemar) wrote :

I dug into this a bit, here are my findings, we have 2 ways to fix this, a quick way, and a way that is, well.. not so quick.

The latter for now, the problem is that from a UX/OSC perspective, I would want the command to work based on knowing my domain name and user name. Even if we change KSC to accept a domain id/name parameter, I'm not sure what to do with it at that point, since it's always going to call get() on the user id. So maybe having another route for GET/domain/domain_id/users/user_id is acceptable here? I'm not sure.

The former, we could leverage the *find* function of the CrudManager class. See here: https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/base.py#L384-L406
It basically calls list, and filters on kwargs, we would obviously filter on domain_id and name, which is great, since those are actually valid filters, yay https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3.md#list-users-get-users

Not sure if you noticed this, but for most of our `show` methods in OSC revolve around this function called `find_resource` It basically does a variety of get calls (and passes on exceptions), until it finally tries to call find, here: https://github.com/openstack/python-openstackclient/blob/master/openstackclient/common/utils.py#L60-L61.

My idea is 1) Change the signature of find_resource to include **kwargs, and remove the line where we set it to {}, then 2) Update https://github.com/openstack/python-openstackclient/blob/master/openstackclient/identity/v3/user.py#L373-L376 to accept an optional domain argument and send it in to find_resource as well. That *should* work.

The reason why this isn't the best is that `find` calls a list, and then it filters, so not the best for performance. But this does beg the question of whether or not we need new functions on the server side to account for finding users/projects/groups within a domain.

Revision history for this message
Steve Martinelli (stevemar) wrote :

Uploaded a patch here: https://review.openstack.org/#/c/126475/ but I lack the environment to test it out, if you could verify that it works that would be great.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to python-openstackclient (master)

Reviewed: https://review.openstack.org/126475
Committed: https://git.openstack.org/cgit/openstack/python-openstackclient/commit/?id=364071a90bfe9dcec1d02a349c33dc8422fc14f3
Submitter: Jenkins
Branch: master

commit 364071a90bfe9dcec1d02a349c33dc8422fc14f3
Author: Steve Martinelli <email address hidden>
Date: Tue Oct 7 02:15:15 2014 -0400

    Add domain parameters to user show for Identity V3

    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

Changed in python-openstackclient:
status: In Progress → Fix Committed
Dean Troyer (dtroyer)
Changed in python-openstackclient:
milestone: none → m6
Dean Troyer (dtroyer)
Changed in python-openstackclient:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.