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
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='')
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
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
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
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!
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
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
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