DevStack has always tried to be mostly-functional with a minimal amount of configuration. The number of options has ballooned as projects add features, new projects added and more combinations need to be tested. Historically DevStack obtained all local configuration and customizations from a localrc
file. The number of configuration variables that are simply passed-through to the individual project configuration files is also increasing. The old mechanism for this (EXTRAS_OPTS
and friends) required specific code for each file and did not scale well.
In Oct 2013 a new configuration method was introduced (in review 46768) to hopefully simplify this process and meet the following goals:
localrc
to smooth the transition processThe new configuration file is local.conf
and resides in the root DevStack directory like the old localrc
file. It is a modified INI format file that introduces a meta-section header to carry additional information regarding the configuration files to be changed.
The new header is similar to a normal INI section header but with double brackets ([[ ... ]]
) and two internal fields separated by a pipe (|
):
[[ <phase> | <config-file-name> ]]
where <phase>
is one of a set of phase names defined by stack.sh
and <config-file-name>
is the configuration filename. The filename is eval'ed in the stack.sh
context so all environment variables are available and may be used. Using the project config file variables in the header is strongly suggested (see the NOVA_CONF
example below). If the path of the config file does not exist it is skipped.
The defined phases are:
localrc
from local.conf
before stackrc
is sourcedextra.d
are executed
The file is processed strictly in sequence; meta-sections may be specified more than once but if any settings are duplicated the last to appear in the file will be used.
[[post-config|$NOVA_CONF]] [DEFAULT] use_syslog = True [osapi_v3] enabled = False
A specific meta-section local|localrc
is used to
provide a default localrc
file (actually
.localrc.auto
). This allows all custom settings
for DevStack to be contained in a single file. If localrc
exists it will be used instead to preserve backward-compatibility. More
details on the contents of localrc are available.
[[local|localrc]] FIXED_RANGE=10.254.1.0/24 ADMIN_PASSWORD=speciale LOGFILE=$DEST/logs/stack.sh.log
Note that Q_PLUGIN_CONF_FILE
is unique in that it is assumed to NOT start with a /
(slash) character. A slash will need to be added:
[[post-config|/$Q_PLUGIN_CONF_FILE]]
Also note that the localrc
section is sourced as a shell script fragment amd =
(equals).
While stack.sh
is happy to run without a localrc
section in local.conf
, devlife is better when there are a few minimal variables set. This is an example of a minimal configuration that touches the values that most often need to be set.
FIXED_RANGE
and FLOATING_RANGE
, commented out below)HOST_IP
, commented out below)[[local|localrc]] ADMIN_PASSWORD=secrete DATABASE_PASSWORD=$ADMIN_PASSWORD RABBIT_PASSWORD=$ADMIN_PASSWORD SERVICE_PASSWORD=$ADMIN_PASSWORD SERVICE_TOKEN=a682f596-76f3-11e3-b3b2-e716f9080d50 #FIXED_RANGE=172.31.1.0/24 #FLOATING_RANGE=192.168.20.0/25 #HOST_IP=10.3.4.5
If the *_PASSWORD
variables are not set here you will be prompted to enter values for them by stack.sh
.
The network ranges must not overlap with any networks in use on the host. Overlap is not uncommon as RFC-1918 'private' ranges are commonly used for both the local networking and Nova's fixed and floating ranges.
HOST_IP
is normally detected on the first run of stack.sh
but often is indeterminate on later runs due to the IP being moved from an Ethernet integace to a bridge on the host. Setting it here also makes it available for openrc
to set OS_AUTH_URL
. HOST_IP
is not set by default.
DEST=/opt/stack
DEST
variable. By setting it early in the localrc
section you can reference it in later variables. It can be useful to set it even though it is not changed from the default value.
DEST=/opt/stack
LOGFILE="" LOGDAYS=7 LOG_COLOR=True
stack.sh
output is only written to the console where is runs. It can be sent to a file in addition to the console by setting LOGFILE
to the fully-qualified name of the destination log file. A timestamp will be appended to the given filename for each run of stack.sh
.
LOGFILE=$DEST/logs/stack.sh.logOld log files are cleaned automatically if
LOGDAYS
is set to the number of days of old log files to keep.
LOGDAYS=1The some of the project logs (Nova, Cinder, etc) will be colorized by default (if
SYSLOG
is not set below); this can be turned off by setting LOG_COLOR
False.
LOG_COLOR=False
SCREEN_LOGDIR=""
screen
which is useful for watching log and debug output. However, in automated testing the interactive screen
sessions may not be available after the fact; setting SCREEN_LOGDIR
enables logging of the screen
sessions in the specified diretory. There will be one file per screen
session named for the session name and a timestamp.
SCREEN_LOGDIR=$DEST/logs/screenNote the use of
DEST
to locate the main install directory; this is why we suggest setting it in local.conf
.SYSLOG=False SYSLOG_HOST=$HOST_IP SYSLOG_PORT=516
SYSLOG
to True
. If the destination log host is not localhost SYSLOG_HOST
and SYSLOG_PORT
can be used to direct the message stream to the log host.
SYSLOG=True SYSLOG_HOST=$HOST_IP SYSLOG_PORT=516
RECLONE=""
stack.sh
only clones the project repos if they do not exist in $DEST
. stack.sh
will freshen each repo on each run if RECLONE
is set to yes
. This avoids having to manually remove repos in order to get the current branch from $GIT_BASE
.
RECLONE=yes
SWIFT_HASH="" SWIFT_REPLICAS=1 SWIFT_DATA_DIR=$DEST/data/swift
ENABLED_SERVICES
) is automatically disabled. Enable Swift by adding it services to ENABLED_SERVICES
:
enable_service s-proxy s-object s-container s-accountSetting Swift's hash value is required and you will be prompted for it if Swift is enabled so just set it to something already:
SWIFT_HASH=66a3d6b56c1f479c8b4e70ab5c2000f5For development purposes the default number of replicas is set to
1
to reduce the overhead required. To better simulate a production deployment set this to 3
or more.
SWIFT_REPLICAS=3The data for Swift is stored in the source tree by default (in
$DEST/swift/data
) and can be moved by setting
SWIFT_DATA_DIR
. The specified directory will be created if it does not exist.
SWIFT_DATA_DIR=$DEST/data/swiftNote: Previously just enabling
swift
was sufficient to start the Swift services. That does not provide proper service granularity, particularly in multi-host configurations, and is considered deprecated. Some service combination tests now check for specific Swift services and the old blanket acceptance will longer work correctly.
KEYSTONE_CATALOG_BACKEND=sql
sql
service catalog backend. An alternate template
backend is also available. However, it does not support the service-*
and endpoint-*
commands of the keystone
CLI. To
do so requires the sql
backend be enabled:
KEYSTONE_CATALOG_BACKEND=templateDevStack's default configuration in
sql
mode is set in
files/keystone_data.sh
VOLUME_GROUP="stack-volumes" VOLUME_NAME_PREFIX="volume-" VOLUME_BACKING_FILE_SIZE=10250M
VOLUME_GROUP
, the logical volume name prefix is set with VOLUME_NAME_PREFIX
and the size of the volume backing file is set with VOLUME_BACKING_FILE_SIZE
.
VOLUME_GROUP="stack-volumes" VOLUME_NAME_PREFIX="volume-" VOLUME_BACKING_FILE_SIZE=10250M
MULTI_HOST=False
local.conf
section for each host. The master is the same as a single host installation with MULTI_HOST=True
. The slaves have fewer services enabled and a couple of host variables pointing to the master.
MULTI_HOST=TrueSlave
MYSQL_HOST=w.x.y.z RABBIT_HOST=w.x.y.z GLANCE_HOSTPORT=w.x.y.z:9292 ENABLED_SERVICES=n-vol,n-cpu,n-net,n-api
API_RATE_LIMIT=True
API_RATE_LIMIT=False
.
API_RATE_LIMIT=False
CINDER_PERIODIC_INTERVAL
):
[[post-config|$CINDER_CONF]] [DEFAULT] periodic_interval = 60
local.conf
with screen logging enabled:
[[local|localrc]] FIXED_RANGE=10.254.1.0/24 NETWORK_GATEWAY=10.254.1.1 LOGDAYS=1 LOGFILE=$DEST/logs/stack.sh.log SCREEN_LOGDIR=$DEST/logs/screen ADMIN_PASSWORD=quiet DATABASE_PASSWORD=$ADMIN_PASSWORD RABBIT_PASSWORD=$ADMIN_PASSWORD SERVICE_PASSWORD=$ADMIN_PASSWORD SERVICE_TOKEN=a682f596-76f3-11e3-b3b2-e716f9080d50