That commit doesn't really address the problem in question though.

The problem is that the OpenStack client assumes the "get user" policy
in Keystone allows you to get your own user, which it didn't until
Newton, and thus a lot of deployments probably are using the default
policy or some variant thereof. Ours is included in this list, and while
I am working on getting our Keystone policy updated to match that
assumption, it makes sense to fix the issue in the openstackclient for
anyone else running into this problem.

What I'd like to do is one of these two options:
- "openstack user project list", a command which will get your id from
your authed token and used it directly with the keystoneclient as such:
"keystoneclient.projects.list(user='<my_user_id>')" which will pipe the
call correctly to: "/v3/users/{user_id}/projects"
- or update "openstack project list" with a "--auth-user" flag that
ignores all other options and directly filters the project list by your
token's user id. This type of option is already present in the "role
assignment list" command. From a UX standpoint part of me feels that
project list should default to --auth-user if your token doesn't have
admin roles, but I'm not sure how easy that would be to do.

There may be other commands that fall over due to a unneeded
resource_find call to get user, but I haven't explored those too much
yet. Chances are any non-admin command which can be filtered by user and
does a resource find first we fall over on anything < Newton.

On 22/09/16 06:31, Steve Martinelli wrote:
> On Wed, Sep 21, 2016 at 1:04 PM, Dolph Mathews
> < <>> wrote:
>     I should also express a +1 for something along the lines of your
>     original proposal. I'd go so far as to suggest that `openstack
>     show user` (without a user ID or name as an argument) should
>     return "me" (the authenticated user), as I think that'd be a
>     better user experience.
> That should be fixed in openstackclient 3.0.0
> -- 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:

OpenStack Development Mailing List (not for usage questions)

Reply via email to