Re: [openstack-dev] [osc][keystone] User Project List
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'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. > > > I prefer this one. The issue with defaulting to --auth-user (this was > proposed at one point) is that it breaks the existing behaviour > (listing all projects). > Alright, will throw up a blueprint and get some code together for this soon. As for the defaulting, since the auth_ref does have your roles can't we just check if an admin (or admin like role) is present? The main problem I see here is the disconnect between actual policy and the chance of a deployment using other role names. Another option being that if a permissions error happens it could default to --auth-user, but that in turn might make some debugging harder. That's why my other suggestion was an entirely separate command, since there is no existing behavior to break and the default then feels the most sensible and clearer for someone trying to list their own projects. I mean, in keystone 'user project list' is a different api endpoint, it's only the keystone client which merges them into one command. ;) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [osc][keystone] User Project List
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='')" 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.
>
I prefer this one. The issue with defaulting to --auth-user (this was
proposed at one point) is that it breaks the existing behaviour (listing
all projects).
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [osc][keystone] User Project List
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 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='')" 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
>> mailto:dolph.math...@gmail.com>> 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
>> --
>> https://github.com/openstack/python-openstackclient/commit/337d013c94378a4b3f0e8f90e4f5bd745448658f
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [osc][keystone] User Project List
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='')" 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
> mailto:dolph.math...@gmail.com>> 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
> --
> https://github.com/openstack/python-openstackclient/commit/337d013c94378a4b3f0e8f90e4f5bd745448658f
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [osc][keystone] User Project List
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 -- https://github.com/openstack/python-openstackclient/commit/337d013c94378a4b3f0e8f90e4f5bd745448658f __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [osc][keystone] User Project List
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! That's certainly true for both liberty and mitaka in both of the policy files: * https://github.com/openstack/keystone/blob/stable/liberty/etc/policy.json#L44 * https://github.com/openstack/keystone/blob/stable/liberty/etc/policy.v3cloudsample.json#L49 * https://github.com/openstack/keystone/blob/stable/mitaka/etc/policy.json#L44 * https://github.com/openstack/keystone/blob/stable/mitaka/etc/policy.v3cloudsample.json#L48 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. > On 22/09/2016 12:58 AM, Dolph Mathews wrote: > > > > > > > > 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 default upstream policy files have allowed for this since about Grizzly > or Havana, unless that's quietly broken somehow. > > > >> > >> > >> > >> > >> > __ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > > -Dolph > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- -Dolph __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [osc][keystone] User Project List
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 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 default upstream policy files have allowed for this since about Grizzly or Havana, unless that's quietly broken somehow. > >> >> >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- > -Dolph __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [osc][keystone] User Project List
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 default upstream policy files have allowed for this since about Grizzly or Havana, unless that's quietly broken somehow. > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- -Dolph __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [osc][keystone] User Project List
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 call, even if you are already passing in a user_id, the client MUST go to Keystone to get your user to be able to filter your project list. The default keystone policy up until Newton doesn't let a user get their own user, and thus that client call falls over despite the ability to use this endpoint just fine: http://developer.openstack.org/api-ref/identity/v3/index.html?expanded=list-projects-for-user-detail#list-projects-for-user Plus doing: "keystoneclient.projects.list(user='')" works just fine. By forcing that resource_find you are making it impossible for anyone to use the client to actually get that a list of their own projects if their Keystone policy is still the old one. To fix this, how do people feel about adding a "user project list" command or even a "--auth-user" option to the "project list" command. In both cases we can get the id from the token and bypass the need for a resource_find. That way it's less API calls, but also compatible with older policies. Any preferences as to which solution? I don't mind writing the blueprint/patch myself, just would like to know the preferred option. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
