Modify startup order of Cinder services.
There are cases where the timing between the start up for cinder-volume and cinder-scheduler service can result in a race where the scheduler doesn't know about the volume-service until the next periodic update. This change does attempts to do an easy fix by swapping the start order of the cinder services to ensure that the scheduler will be able to receive the volume service capabilities update. Fixes bug: 1189595 Change-Id: I8f477ddc04c15c04493f7ce6863e08e1de8f0128
This commit is contained in:
parent
7e3efc6a33
commit
e6d4fe5f0f
@ -474,9 +474,13 @@ function start_cinder() {
|
||||
fi
|
||||
|
||||
screen_it c-api "cd $CINDER_DIR && $CINDER_BIN_DIR/cinder-api --config-file $CINDER_CONF"
|
||||
screen_it c-vol "cd $CINDER_DIR && $CINDER_BIN_DIR/cinder-volume --config-file $CINDER_CONF"
|
||||
screen_it c-sch "cd $CINDER_DIR && $CINDER_BIN_DIR/cinder-scheduler --config-file $CINDER_CONF"
|
||||
screen_it c-bak "cd $CINDER_DIR && $CINDER_BIN_DIR/cinder-backup --config-file $CINDER_CONF"
|
||||
screen_it c-vol "cd $CINDER_DIR && $CINDER_BIN_DIR/cinder-volume --config-file $CINDER_CONF"
|
||||
|
||||
# NOTE(jdg): For cinder, startup order matters. To ensure that repor_capabilities is received
|
||||
# by the scheduler start the cinder-volume service last (or restart it) after the scheduler
|
||||
# has started. This is a quick fix for lp bug/1189595
|
||||
|
||||
# Start proxies if enabled
|
||||
if is_service_enabled c-api && is_service_enabled tls-proxy; then
|
||||
|
Loading…
Reference in New Issue
Block a user