This functionality is needed to deploy a "shared Keystone" multi-site architecture. In this architecture, each site is a separate OpenStack region, but the Keystone services all use a shared, replicated database.
This Keystone database will be manually deployed on a minimum of 3 servers, in separate locations. Galera will be used to replicate the keystone database between these servers. Some of these servers *may* be co-located with the OpenStack deployment.
Each site will have a local database VIP, which will be managed by pacemaker on the controller cluster and assigned to one of the controller hosts. HAProxy will listen on that VIP and forward connections to the actual DB servers, with a strong preference for any local server(s).
The following information will be provided in an environment file:
- local Keystone DB servers (0 or more IP/hostname[:port] combinations)
- remote Keystone DB servers (2 or more IP/hostname[:port] combinations)
- database name (default to keystone)
- database credentials
- local Keystone database VIP (optional)
A few additional thoughts around this ...
We believe that we won't hit the SELECT ... FOR UPDATE issue that forces us to use a single Galera writer in the general case:
Rolling N+1 upgrades should be possible by following the correct procedure:
This may require logic to disable the db_sync command that we use to upgrade the database schema in the normal upgrade case.
Also, we're going to want to put each region's service accounts (neutron, heat, nova, ... maybe admin) into a separate region-specific Keystone domain in order to avoid collisions between the different regions. This domain will still use "local" (Keystone database) storage, and is distinct from the Active Directory/LDAP/SAML/etc. domain(s) used for normal user authentication. I'm not sure if this is possible with TripleO today.
*** Bug 1368965 has been marked as a duplicate of this bug. ***
Closing as WONT FIX. Upstream is presently holding discussions related to how Keystone will fit into the Edge model.