v3 Region API
A region is currently an attribute of an endpoint, which are only provided to clients after authenticating.
- Regions should support first-class CRUD operations on /v3/regions
- Regions should be hierarchical with an optional reference to a parent region
- It should be possible to request an unauthenticated service catalog from keystone (a vanilla deployment may only return a single identity endpoint in such a catalog).
Related Havana summit etherpad: https:/
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Medium
- Drafter:
- None
- Direction:
- Approved
- Assignee:
- Jay Pipes
- Definition:
- Approved
- Series goal:
- Accepted for icehouse
- Implementation:
-
Implemented
- Milestone target:
-
2014.1
- Started by
- Thierry Carrez
- Completed by
- Dolph Mathews
Related branches
Related bugs
Sprints
Whiteboard
Related blueprint to publish the catalog independently from auth (although the response may be based on the user's auth): https:/
Related use case described by https:/
API: https:/
API: https:/
Gerrit topic: https:/
Addressed by: https:/
Implements regions resource in 3.2 Catalog API
Work Items
Work items:
Add /regions resource to v3 API spec in identity-api: TODO
Add simple templated and KVS backends for region resource in keystone: TODO
Add SQL backend for region resource in keystone: TODO