support name and id in role,user,tenant query
If you create a role/user/tenant with a name that already exists, it will return a HTTP 409
e.g. Conflict occurred attempting to store user.
The name has uniqueness. This means that you can query a role/user/tenant with its name.
In python-
python-
@utils.arg('user', metavar='<user>', help='Name or ID of user to display.')
def do_user_get(kc, args):
"""Display user details."""
user = utils.find_
utils.
The python-
Then test keystone api call directly:
set user_id in the resource url:
curl -i -X GET http://
HTTP/1.1 200 OK
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 138
Date: Wed, 07 Jan 2015 03:15:51 GMT
{"user": {"username": "admin", "name": "admin", "enabled": true, "email": "<email address hidden>", "id": "e9f5188d12c043
set username in the resource url:
curl -i -X GET http://
HTTP/1.1 404 Not Found
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 88
Date: Wed, 07 Jan 2015 03:16:02 GMT
{"error": {"message": "Could not find user, admin.", "code": 404, "title": "Not Found"}}
V3 api has the same result.
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- LIU Yulong
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
- Unknown
- Milestone target:
- None
- Started by
- Completed by
- Steve Martinelli
Related branches
Related bugs
Sprints
Whiteboard
(stevemar 16-02-02): i don't think this is something we want to pursue. not all backends (sql vs ldap) will create conflicts if the name matches, and different backend implementation each act differently.
the APIs are well-defined, the resource ID should be used to get the resource. sometimes the name happens to be unique for some resources, not always.
further, i am not clear on the use case that this feature will add. we offer listing resources with support for filtering by attributes (i.e. name), which many clients support.
further, this should go through the new spec proposal process at specs.openstack
marking this as obsolete