Refresh keystone after deployment
This is necessary for certain setups (such as enabling multiple LDAP domains). So, instead of always adding checks every time to see if we need to refresh or not, lets just do it always, thus simplifying the already convoluted logic here. Change-Id: Ie1a0b9740ed18663451a3907ec3e3575adb4e778 Closes-Bug: #1748219 Co-Authored-By: Raildo Mascena <rmascena@redhat.com>
This commit is contained in:
parent
14af18e393
commit
ffc14e3067
@ -188,6 +188,18 @@ outputs:
|
||||
- /var/lib/config-data/puppet-generated/keystone/:/var/lib/kolla/config_files/src:ro
|
||||
environment:
|
||||
- KOLLA_CONFIG_STRATEGY=COPY_ALWAYS
|
||||
step_4:
|
||||
# There are cases where we need to refresh keystone after the resource provisioning,
|
||||
# such as the case of using LDAP backends for domains. So we trigger a graceful
|
||||
# restart [1], which shouldn't cause service disruption, but will reload new
|
||||
# configurations for keystone.
|
||||
# [1] https://httpd.apache.org/docs/2.4/stopping.html#graceful
|
||||
keystone_refresh:
|
||||
start_order: 1
|
||||
action: exec
|
||||
user: root
|
||||
command:
|
||||
[ 'keystone', 'pkill', '--signal', 'USR1', 'httpd' ]
|
||||
docker_puppet_tasks:
|
||||
# Keystone endpoint creation occurs only on single node
|
||||
step_3:
|
||||
|
Loading…
x
Reference in New Issue
Block a user