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
