Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

keystone Identity Admin API v2.0 behavior RHEL OS -vs- Community OS

Hi,

I've noticed there's a difference between the way the RHEL OS and Community OS identity admin apis work and I'm hoping someone can provide a little perspective on what I'm seeing. Specifically, it looks like this API is expecting different values for {user-id} on different releases of OS:

/v2.0/tenants/{tenant-id}/users/{user-id}/roles

We are currently testing our product on Community Icehouse/Juno/Kilo as well as RHEL Kilo.

On Community Icehouse/Juno/Kilo, we are passing a user name for {user-id}:

$ curl -H "X-Auth-Token:$ostoken" http://keystone.somedomain.com:35357/v2.0/tenants/02b3cc5d8e0b420e8a15777f9a7d6420/users/rshoemaker/roles
{"roles": [{"id": "9fe2ff9ee4384b1894a90878d3e92bab", "name": "_member_"}]}

If we pass a user id, then we get a 404:

$ curl -H "X-Auth-Token:$ostoken" http://keystone.somedomain.com:35357/v2.0/tenants/02b3cc5d8e0b420e8a15777f9a7d6420/users/9fe2ff9ee4384b1894a90878d3e92bab/roles
{"error": {"message": "Could not find user: 9fe2ff9ee4384b1894a90878d3e92bab", "code": 404, "title": "Not Found"}}

On RHEL Kilo, if we pass the user name in, we get a 404:

$ curl -H "X-Auth-Token:$ostoken" http://rh-openstack.somedomain.com:35357/v2.0/tenants/1f6807689c904d6f9824fa3d202f5743/users/rshoemaker/roles
{"error": {"message": "Could not find user: rshoemaker", "code": 404, "title": "Not Found"}}

But if we pass the user id it works fine:

$ curl -H "X-Auth-Token:$ostoken" http://rh-openstack.somedomain.com:35357/v2.0/tenants/1f6807689c904d6f9824fa3d202f5743/users/3cf1b596585e419dac0c3bb94fd2f3b5/roles
{"roles": [{"id": "9fe2ff9ee4384b1894a90878d3e92bab", "name": "_member_"}]}

So, to summarize:

  • RHEL Kilo expects user ids and fails on user names
  • Community Icehouse/Juno/Kilo expect user names and fails on user ids

Can anyone explain why there's a difference? I'd almost feel better if Community Kilo and RHEL Kilo worked the same, but perhaps this is a case when RH changed the code to accept a user-id instead.

Based on the OS docs here, it certainly seems like the API was meant to take a user-id, not a user-name.