Support Keystone Regions
Exosphere needs to support Keystone regions for Jetstream 2.
Jetstream 2 will have the "main" region at IU Bloomington, and "satellite" regions at ASU, Cornell, Hawaii, and TACC. This means that OpenStack service endpoints will multiply; we will have a set of endpoints for each region.
For review:
- A region is an entirely separate OpenStack deployment with its own API endpoints, except for Keystone and Horizon
- Main region has the Keystone and the Horizon; it hands out endpoints for services in all the other regions.
We need to:
- Work to understand the capabilities and limitations that regions introduce. For example, we can't attach a volume in region A to a server in region B. So, regions behave mostly as separate providers that happen to share an auth/identity service.
- How are regions exposed by the Keystone API?
- An
openstack endpoint list
on the CLI returns aRegion
column, presumably endpoints multiply as regions multiply.
- An
- How does Horizon surface this?
- How are regions exposed by the Keystone API?
- Figure out the data structures and semantics inside Exosphere to represent regions.
- Figure out how to surface this in the UI. We could start by showing them as different projects/providers, and perhaps group them (e.g. in the left-hand nav) if they share a common Keystone.
Success criteria:
- User can log into main Keystone and access projects across all regions without having to log in again; the experience is not confusing
- On a simple cloud where everything is in one default region, Exosphere's multi-region support does not complicate the UX unnecessarily or get in the way.
- Exosphere prevents user from performing operations that would not work across regions (e.g. attaching volume from region A to server in region B)'
Edited by Chris Martin