Add new parameter RECREATE_KEYSTONE_DB
If 'RECREATE_KEYSTONE_DB=False' database won't be recreated.
It would be useful for multinode Grenade tests for Keystone. This parameter
will help us to deploy multiple services on different machines talking to
the same DB.
Devstack recreates Keystone DB each time during Keystone service installation.
If our controller node is already deployed, Keystone DB already contains
important information about OpenStack services and their endpoints. When
the second Keystone node is being deployed, we don't want to delete
records about controllers' services endpoints.
Partially-Implements: bp rolling-upgrade-testing
Change-Id: Ia8d07b4295ca165be01e44466c95d5275f596e83
diff --git a/lib/keystone b/lib/keystone
index fd1d1d4..0d54dee 100644
--- a/lib/keystone
+++ b/lib/keystone
@@ -488,8 +488,10 @@
init_ldap
fi
- # (Re)create keystone database
- recreate_database keystone
+ if [[ "$RECREATE_KEYSTONE_DB" == True ]]; then
+ # (Re)create keystone database
+ recreate_database keystone
+ fi
# Initialize keystone database
$KEYSTONE_BIN_DIR/keystone-manage --config-file $KEYSTONE_CONF db_sync
diff --git a/stackrc b/stackrc
index e7771cf..ae87b22 100644
--- a/stackrc
+++ b/stackrc
@@ -819,6 +819,10 @@
# Use native SSL for servers in ``SSL_ENABLED_SERVICES``
USE_SSL=$(trueorfalse False USE_SSL)
+# We may not need to recreate database in case 2 Keystone services
+# sharing the same database. It would be useful for multinode Grenade tests.
+RECREATE_KEYSTONE_DB=$(trueorfalse True RECREATE_KEYSTONE_DB)
+
# ebtables is inherently racey. If you run it by two or more processes
# simultaneously it will collide, badly, in the kernel and produce
# failures or corruption of ebtables. The only way around it is for