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='<my_user_id>')" 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

Reply via email to