Essex Keystone service Endpoint Location
Today, Keystone distinguishes service endpoints by Service Name/Type and Region. We would like to propose a change to the endpoint schema to allow further delineation by introducing a new complex type ‘location’ and attribute ‘locationType’. The complex type describes the location of the endpoint and allows clients to choose services based on geography, region, and zone. This can be extremely useful when privacy laws might dictate which geography, thus service endpoint you use when storing certain types of information. Additionally, allowing a client to distinguish to the zone level can be beneficial in supporting client controlled HA within a region. Location type would be a required attribute based on an enumeration that clients could use to help them understand how, and whether, to consume the optional elements of location. For example, if the location type is ‘enterprise’ then clients probably do not care about zone, region, and geography. However, if the location type where cloud, then a client would want to consume the location information to help draw further distinctions on service endpoint.
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Medium
- Drafter:
- Jason Rouault
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
- Not started
- Milestone target:
- None
- Started by
- Completed by
- Joseph Heck
Related branches
Related bugs
Sprints
Whiteboard
Questions
1. Will region become part of the location complexType or stay within the endpoint complexType?
2. This looks good, but must be in a separate namespace. In the json, this means it must be prefixed (extension name as an example). Same process like the other extension enhancements.
Per gyee in today's (January 10th) openstack meeting, this will not make e3.