Bug 1412816

Summary: [RFE] Multi-site: deploy overcloud using pre-existing Keystone database
Product: Red Hat OpenStack Reporter: Ian Pilcher <ipilcher>
Component: openstack-tripleo-heat-templatesAssignee: Jiri Stransky <jstransk>
Status: CLOSED WONTFIX QA Contact: Arik Chernetsky <achernet>
Severity: unspecified Docs Contact:
Priority: high    
Version: 11.0 (Ocata)CC: hrybacki, jcoufal, mburns, nkinder, rcritten, rhel-osp-director-maint, royoung, scohen, taosawa, yohmura
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-12-08 18:14:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1476902, 1592486    

Description Ian Pilcher 2017-01-12 21:30:07 UTC
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)

Comment 2 Ian Pilcher 2017-01-26 16:47:21 UTC
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:

  https://bugs.launchpad.net/keystone/+bug/1325143

Rolling N+1 upgrades should be possible by following the correct procedure:

  https://specs.openstack.org/openstack/keystone-specs/specs/keystone/newton/manage-migration.html

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.

Comment 5 Chris Jones 2018-01-08 16:25:44 UTC
*** Bug 1368965 has been marked as a duplicate of this bug. ***

Comment 8 Harry Rybacki 2018-12-08 18:14:21 UTC
Closing as WONT FIX. Upstream is presently holding discussions related to how Keystone will fit into the Edge model.