openstack team mailing list archive

[Luis Gervaso <luis@xxxxxxxxx>]

Hi Everett,

I just uploaded a video showing all the issues i found:

http://youtu.be/TXw7h9Kl-Ow

As you can show, I can't drill down to roles related info from user if i
haven't selected a tenant or the user does
not have a default tenantId

>From administrative tasks should be useful list tenants from userId (not
only from X-AuthToken), so I hope this to
be included in the ws api sooner or later ;)

Note : This is using OpenStack Java SDK

On Fri, May 4, 2012 at 6:51 PM, Everett Toews <everett.toews@xxxxxxxxx>wrote:

> Hi Luis,
>
> I'm digging around in the Keystone code right now and helping answer your
> questions is helping me learn the code base. Keep 'em coming!
>
> Anyway, from what I can tell, you're correct that there's no general way
> to get all of the tenants that a user belongs to in the current high level
> API. However, there is already support for exactly this feature in the
> lower level API. In [1] you'll see that the Driver object has the
> method get_tenants_for_user. This method is implemented in all of the
> backends in [2] so there's support for it everywhere, it just hasn't been
> exposed in the high level API. Looking closer at [1] we see the comment,
>
> # NOTE(termie): seven calls below should probably be exposed by the api
> #               more clearly when the api redesign happens
>
> which includes the method get_tenants_for_user. Looks like it's just a
> matter of adding this method to one of the Routers to make it available in
> the REST API.
>
> My advice to you is to track down termie and find out what the story is
> with the API redesign he mentions. Of course, you could always propose a
> blueprint to [3] and make the method available yourself ;)
>
> Hope this helps,
> Everett
>
> [1]
> https://github.com/openstack/keystone/blob/master/keystone/identity/core.py
> [2]
> https://github.com/openstack/keystone/tree/master/keystone/identity/backends
> [3] https://blueprints.launchpad.net/keystone
>
> On Thu, May 3, 2012 at 5:27 PM, Luis Gervaso <luis@xxxxxxxxx> wrote:
>
>> From admin port I want to list the tenants a user (different from the
>> current user) belongs to.
>>
>>
>> On Fri, May 4, 2012 at 1:24 AM, Gabriel Hurley <Gabriel.Hurley@xxxxxxxxxx
>> > wrote:
>>
>>>  On the keystone admin port the tenants call will list all tenants
>>> (provided the token corresponds to a user who has admin privileges).****
>>>
>>> ** **
>>>
>>> **-          **Gabriel****
>>>
>>> ** **
>>>
>>> *From:* openstack-bounces+gabriel.hurley=nebula.com@xxxxxxxxxxxxxxxxxxx[mailto:
>>> openstack-bounces+gabriel.hurley=nebula.com@xxxxxxxxxxxxxxxxxxx] *On
>>> Behalf Of *Luis Gervaso
>>> *Sent:* Thursday, May 03, 2012 1:24 PM
>>> *To:* Everett Toews
>>> *Cc:* openstack@xxxxxxxxxxxxxxxxxxx
>>> *Subject:* Re: [Openstack] Keystone API question****
>>>
>>> ** **
>>>
>>> Yes, this is the real issue.****
>>>
>>> ** **
>>>
>>> Since /tenants is only valid for the current user (that's X-Auth-Token
>>> dependant)****
>>>
>>> ** **
>>>
>>> How can an administrator user list all the tenants a user belongs to?***
>>> *
>>>
>>> ** **
>>>
>>> Another issue i've detected is that endpoints are always dependant on a
>>> service,****
>>>
>>> may be i'm wrong but for me:****
>>>
>>> ** **
>>>
>>> /service/{service_id}/endpoints****
>>>
>>> ** **
>>>
>>> is more appropiate than****
>>>
>>> ** **
>>>
>>> /endpoints****
>>>
>>> ** **
>>>
>>> Dolph, please correct me****
>>>
>>> ** **
>>>
>>> Luis****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> On Thu, May 3, 2012 at 10:12 PM, Everett Toews <everett.toews@xxxxxxxxx>
>>> wrote:****
>>>
>>> I get the same as Luis when trying GET /users/{user_id}/roles on
>>> stable/essex (using devstack). Keystone spits back an****
>>>
>>> ** **
>>>
>>> AttributeError: 'UserController' object has no attribute 'get_user_roles'
>>> ****
>>>
>>> ** **
>>>
>>> message instead of a nice 501.****
>>>
>>> ** **
>>>
>>> GET /tenants/{tenant_id}/users/{user_id}/roles works fine. For a bit
>>> more detail have a look at****
>>>
>>> ** **
>>>
>>>
>>> http://docs.openstack.org/api/openstack-identity-service/2.0/content/GET_listRolesForUserOnTenant_v2.0_tenants__tenantId__users__user_id__roles_Admin_API_Service_Developer_Operations-d1e1356.html
>>> ****
>>>
>>> ** **
>>>
>>> Everett****
>>>
>>> ** **
>>>
>>> On Thu, May 3, 2012 at 9:34 AM, Dolph Mathews <dolph.mathews@xxxxxxxxx>
>>> wrote:****
>>>
>>> The philosophy in essex is that it's meaningless for a user to have a
>>> role without that role being applied to a tenant, so the call that's
>>> implemented is:****
>>>
>>> ** **
>>>
>>>     GET /tenants/{tenant_id}/users/{user_id}/roles****
>>>
>>> ** **
>>>
>>> Calling this instead should get you an HTTP 501 stating "User roles not
>>> supported: tenant ID required".****
>>>
>>> ** **
>>>
>>>     GET /users/{user_id}/roles****
>>>
>>> ** **
>>>
>>> Also, the term "roleRefs" was deprecated late in the diablo cycle
>>> (AFAIK) in favor of "roles".****
>>>
>>> ** **
>>>
>>> -Dolph****
>>>
>>> ** **
>>>
>>> On Wed, May 2, 2012 at 3:44 PM, Luis Gervaso <luis@xxxxxxxxx> wrote:****
>>>
>>>  Hi,****
>>>
>>> ** **
>>>
>>> In Diablo was:****
>>>
>>> ** **
>>>
>>> GET /users/{user_id}/roleRefs
>>> ****
>>>
>>> ** **
>>>
>>> In Essex it is maintained for compatibility reasons. I understand that
>>> this is the obsolete now.****
>>>
>>> ** **
>>>
>>> I can find:****
>>>
>>> ** **
>>>
>>> PUT & DELETE /users/{user_id}/roles/OS-KSADM/{role_id}****
>>>
>>> ** **
>>>
>>> How can get all the roles having a user_id?****
>>>
>>> ** **
>>>
>>> GET /users/{user_id}/roles (i can't find this on stable/essex)****
>>>
>>> ** **
>>>
>>> Returning role list with tenant associated****
>>>
>>> ** **
>>>
>>> Another option that would work for me is:****
>>>
>>> ** **
>>>
>>> GET /users/{user_id}/tenants****
>>>
>>> ** **
>>>
>>> Returning tenant list with role list associated per tenant****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> When i GET /user/{user_id} i obtain only this info****
>>>
>>> ** **
>>>
>>> {"user": {"name": "admin", "enabled": true, "email": "admin@xxxxxxxxxxx",
>>> "id": "ef1e63df85b641d7bf3c575bb8670cef", "tenantId": null}}
>>> ****
>>>
>>> ** **
>>>
>>> Regards****
>>>
>>> ** **
>>>
>>> --
>>> -------------------------------------------
>>> Luis Alberto Gervaso Martin****
>>>
>>> Woorea Solutions, S.L
>>> CEO & CTO
>>> mobile: (+34) 627983344
>>> luis@ <luis.gervaso@xxxxxxxxx>woorea.es****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp****
>>>
>>>  ** **
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp****
>>>
>>> ** **
>>>
>>>
>>>
>>> ****
>>>
>>> ** **
>>>
>>> --
>>> -------------------------------------------
>>> Luis Alberto Gervaso Martin****
>>>
>>> Woorea Solutions, S.L
>>> CEO & CTO
>>> mobile: (+34) 627983344
>>> luis@ <luis.gervaso@xxxxxxxxx>woorea.es****
>>>
>>> ** **
>>>
>>
>>
>>
>> --
>> -------------------------------------------
>> Luis Alberto Gervaso Martin
>> Woorea Solutions, S.L
>> CEO & CTO
>> mobile: (+34) 627983344
>> luis@ <luis.gervaso@xxxxxxxxx>woorea.es
>>
>>
>


-- 
-------------------------------------------
Luis Alberto Gervaso Martin
Woorea Solutions, S.L
CEO & CTO
mobile: (+34) 627983344
luis@ <luis.gervaso@xxxxxxxxx>woorea.es