On 22/09/16 10:45, Steve Martinelli wrote:
> On Wed, Sep 21, 2016 at 6:34 PM, Adrian Turjak
> <adri...@catalyst.net.nz <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

Reply via email to