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:
John Griffith 2013-07-15 17:35:54 -06:00
parent 7e3efc6a33
commit e6d4fe5f0f

View File

@ -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