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.to...@cybera.ca>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 <l...@woorea.es> 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.hur...@nebula.com >> > 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....@lists.launchpad.net[mailto: >>> openstack-bounces+gabriel.hurley=nebula....@lists.launchpad.net] *On >>> Behalf Of *Luis Gervaso >>> *Sent:* Thursday, May 03, 2012 1:24 PM >>> *To:* Everett Toews >>> *Cc:* openstack@lists.launchpad.net >>> *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.to...@cybera.ca> >>> 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.math...@gmail.com> >>> 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 <l...@woorea.es> 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": "ad...@example.com", >>> "id": "ef1e63df85b641d7bf3c575bb8670cef", "tenantId": null}} >>> **** >>> >>> ** ** >>> >>> Regards**** >>> >>> ** ** >>> >>> -- >>> ------------------------------------------- >>> Luis Alberto Gervaso Martin**** >>> >>> Woorea Solutions, S.L >>> CEO & CTO >>> mobile: (+34) 627983344 >>> luis@ <luis.gerv...@gmail.com>woorea.es**** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~openstack >>> Post to : openstack@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~openstack >>> More help : https://help.launchpad.net/ListHelp**** >>> >>> ** ** >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~openstack >>> Post to : openstack@lists.launchpad.net >>> 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.gerv...@gmail.com>woorea.es**** >>> >>> ** ** >>> >> >> >> >> -- >> ------------------------------------------- >> Luis Alberto Gervaso Martin >> Woorea Solutions, S.L >> CEO & CTO >> mobile: (+34) 627983344 >> luis@ <luis.gerv...@gmail.com>woorea.es >> >> > -- ------------------------------------------- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO & CTO mobile: (+34) 627983344 luis@ <luis.gerv...@gmail.com>woorea.es
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
