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:
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:

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

Reply via email to