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


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:


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"
{"roles": [{"id": "9fe2ff9ee4384b1894a90878d3e92bab", "name": "_member_"}]}

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

$ curl -H "X-Auth-Token:$ostoken"
{"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"
{"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"
{"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.