devstack/lib/dlm
Ian Wienand 523f488036 Namespace XTRACE commands
I noticed this when debugging some grenade issues failures.

An include of grenade/functions stores the current value of XTRACE
(on) and disables xtrace for the rest of the import.

We then include devstack's "functions" library, which now overwrites
the stored value of XTRACE the current state; i.e. disabled.

When it finishes it restores the prior state (disabled), and then
grenade restores the same value of XTRACE (disabled).

The result is that xtrace is incorrectly disabled until the next time
it just happens to be turned on.

The solution is to name-space the store of the current-value of xtrace
so when we finish sourcing a file, we always restore the tracing value
to what it was when we entered.

Some files had already discovered this.  In general there is
inconsistency around the setting of the variable, and a lot of obvious
copy-paste.  This brings consistency across all files by using
_XTRACE_* prefixes for the sotre/restore of tracing values.

Change-Id: Iba7739eada5711d9c269cb4127fa712e9f961695
2015-11-27 15:36:04 +11:00

109 lines
2.8 KiB
Bash

#!/bin/bash
#
# lib/dlm
#
# Functions to control the installation and configuration of software
# that provides a dlm (and possibly other functions). The default is
# **zookeeper**, and is going to be the only backend supported in the
# devstack tree.
# Dependencies:
#
# - ``functions`` file
# ``stack.sh`` calls the entry points in this order:
#
# - is_dlm_enabled
# - install_dlm
# - configure_dlm
# - cleanup_dlm
# Save trace setting
_XTRACE_DLM=$(set +o | grep xtrace)
set +o xtrace
# Defaults
# --------
# <define global variables here that belong to this project>
# Set up default directories
ZOOKEEPER_DATA_DIR=$DEST/data/zookeeper
ZOOKEEPER_CONF_DIR=/etc/zookeeper
# Entry Points
# ------------
#
# NOTE(sdague): it is expected that when someone wants to implement
# another one of these out of tree, they'll implement the following
# functions:
#
# - dlm_backend
# - install_dlm
# - configure_dlm
# - cleanup_dlm
# This should be declared in the settings file of any plugin or
# service that needs to have a dlm in their environment.
function use_dlm {
enable_service $(dlm_backend)
}
# A function to return the name of the backend in question, some users
# are going to need to know this.
function dlm_backend {
echo "zookeeper"
}
# Test if a dlm is enabled (defaults to a zookeeper specific check)
function is_dlm_enabled {
[[ ,${ENABLED_SERVICES}, =~ ,"$(dlm_backend)", ]] && return 0
return 1
}
# cleanup_dlm() - Remove residual data files, anything left over from previous
# runs that a clean run would need to clean up
function cleanup_dlm {
# NOTE(sdague): we don't check for is_enabled here because we
# should just delete this regardless. Some times users updated
# their service list before they run cleanup.
sudo rm -rf $ZOOKEEPER_DATA_DIR
}
# configure_dlm() - Set config files, create data dirs, etc
function configure_dlm {
if is_dlm_enabled; then
sudo cp $FILES/zookeeper/* $ZOOKEEPER_CONF_DIR
sudo sed -i -e 's|.*dataDir.*|dataDir='$ZOOKEEPER_DATA_DIR'|' $ZOOKEEPER_CONF_DIR/zoo.cfg
# clean up from previous (possibly aborted) runs
# create required data files
sudo rm -rf $ZOOKEEPER_DATA_DIR
sudo mkdir -p $ZOOKEEPER_DATA_DIR
# restart after configuration, there is no reason to make this
# another step, because having data files that don't match the
# zookeeper running is just going to cause tears.
restart_service zookeeper
fi
}
# install_dlm() - Collect source and prepare
function install_dlm {
if is_dlm_enabled; then
if is_ubuntu; then
install_package zookeeperd
else
die $LINENO "Don't know how to install zookeeper on this platform"
fi
fi
}
# Restore xtrace
$_XTRACE_DLM
# Tell emacs to use shell-script-mode
## Local variables:
## mode: shell-script
## End: