Re: [openstack-dev] [osc][keystone] User Project List

2016-09-21 Thread Adrian Turjak
On 22/09/16 10:45, Steve Martinelli wrote: > On Wed, Sep 21, 2016 at 6:34 PM, Adrian Turjak > mailto:adri...@catalyst.net.nz>> wrote: > > - or update "openstack project list" with a "--auth-user" flag > that ignores all other options and directly filters the project > list by your token

Re: [openstack-dev] [osc][keystone] User Project List

2016-09-21 Thread Steve Martinelli
On Wed, Sep 21, 2016 at 6:34 PM, Adrian Turjak wrote: > > > 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='')

Re: [openstack-dev] [osc][keystone] User Project List

2016-09-21 Thread Adrian Turjak
Worth noting, I have been playing with 3.2.0 and the same problem persists in our deployment which is running a variant of the old default keystone policy. On 22/09/16 10:34, Adrian Turjak wrote: > That commit doesn't really address the problem in question though. > > The problem is that the Open

Re: [openstack-dev] [osc][keystone] User Project List

2016-09-21 Thread Adrian Turjak
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 t

Re: [openstack-dev] [osc][keystone] User Project List

2016-09-21 Thread Steve Martinelli
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 t

Re: [openstack-dev] [osc][keystone] User Project List

2016-09-21 Thread Dolph Mathews
On Wed, Sep 21, 2016 at 9:03 AM Adrian Turjak wrote: > Nope, default keystone policy has not allowed you to get your own user > until this patch was merged: > > https://github.com/openstack/keystone/commit/c990ec5c144d9b1408d47cb83cb0b3d6aeed0d57 > > Sad but true it seems. :( > Wow, you're right!

Re: [openstack-dev] [osc][keystone] User Project List

2016-09-21 Thread Adrian Turjak
Nope, default keystone policy has not allowed you to get your own user until this patch was merged: https://github.com/openstack/keystone/commit/c990ec5c144d9b1408d47cb83cb0b3d6aeed0d57 Sad but true it seems. :( On 22/09/2016 12:58 AM, Dolph Mathews wrote: > > > > On Wed, Sep 21, 2016 at 12:31 AM

Re: [openstack-dev] [osc][keystone] User Project List

2016-09-21 Thread Dolph Mathews
On Wed, Sep 21, 2016 at 12:31 AM Adrian Turjak wrote: > The default keystone policy up until Newton doesn't let a user get their > own user > This seems to be the crutch of your issue - can you provide an example of this specific failure and the corresponding policy? As far as I'm aware, the def

[openstack-dev] [osc][keystone] User Project List

2016-09-20 Thread Adrian Turjak
I'm running into what doesn't really seem like a sensible design choice around how 'openstack project list' handles the user filter. Because of this here: https://github.com/openstack/python-openstackclient/blob/master/openstackclient/identity/v3/project.py#L199 and because of the find_resource ca