Merge "Move horizon apache root to /dashboard"
diff --git a/doc/source/configuration.rst b/doc/source/configuration.rst
index 6052576..90b7d44 100644
--- a/doc/source/configuration.rst
+++ b/doc/source/configuration.rst
@@ -2,6 +2,10 @@
Configuration
=============
+.. contents::
+ :local:
+ :depth: 1
+
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.
@@ -24,8 +28,10 @@
local.conf
==========
-The new configuration file is ``local.conf`` and resides in the root
-DevStack directory like the old ``localrc`` file. It is a modified INI
+The new configuration file is ``local.conf`` and should reside in the
+root Devstack directory. An example of such ``local.conf`` file
+is provided in the ``devstack/samples`` directory. Copy this file into
+the root Devstack directory and adapt it to your needs. It is a modified INI
format file that introduces a meta-section header to carry additional
information regarding the configuration files to be changed.
@@ -142,36 +148,96 @@
Setting it here also makes it available for ``openrc`` to set ``OS_AUTH_URL``.
``HOST_IPV6`` is not set by default.
-Common Configuration Variables
-==============================
+Configuration Notes
+===================
+
+.. contents::
+ :local:
Installation Directory
----------------------
- | *Default: ``DEST=/opt/stack``*
- | The DevStack install directory is set by the ``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.
- |
+The DevStack install directory is set by the ``DEST`` variable. By
+default it is ``/opt/stack``.
+
+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
+Logging
+-------
+
+Enable Logging
+~~~~~~~~~~~~~~
+
+By default ``stack.sh`` output is only written to the console where it
+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.log
+
+Old log files are cleaned automatically if ``LOGDAYS`` is set to the
+number of days of old log files to keep.
+
+ ::
+
+ LOGDAYS=1
+
+The 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`` to ``False``.
+
+ ::
+
+ LOG_COLOR=False
+
+Logging the Service Output
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+DevStack will log the ``stdout`` output of the services it starts.
+When using ``screen`` this logs the output in the screen windows to a
+file. Without ``screen`` this simply redirects stdout of the service
+process to a file in ``LOGDIR``.
+
+ ::
+
+ LOGDIR=$DEST/logs
+
+*Note the use of ``DEST`` to locate the main install directory; this
+is why we suggest setting it in ``local.conf``.*
+
+Enabling Syslog
+~~~~~~~~~~~~~~~
+
+Logging all services to a single syslog can be convenient. Enable
+syslogging by setting ``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
+
Libraries from Git
------------------
- | *Default: ``LIBS_FROM_GIT=""``*
-
- | By default devstack installs OpenStack server components from
- git, however it installs client libraries from released versions
- on pypi. This is appropriate if you are working on server
- development, but if you want to see how an unreleased version of
- the client affects the system you can have devstack install it
- from upstream, or from local git trees.
- | Multiple libraries can be specified as a comma separated list.
- |
+By default devstack installs OpenStack server components from git,
+however it installs client libraries from released versions on pypi.
+This is appropriate if you are working on server development, but if
+you want to see how an unreleased version of the client affects the
+system you can have devstack install it from upstream, or from local
+git trees by specifying it in ``LIBS_FROM_GIT``. Multiple libraries
+can be specified as a comma separated list.
::
@@ -180,99 +246,37 @@
Virtual Environments
--------------------
- | *Default: ``USE_VENV=False``*
- | Enable the use of Python virtual environments by setting ``USE_VENV``
- to ``True``. This will enable the creation of venvs for each project
- that is defined in the ``PROJECT_VENV`` array.
+Enable the use of Python virtual environments by setting ``USE_VENV``
+to ``True``. This will enable the creation of venvs for each project
+that is defined in the ``PROJECT_VENV`` array.
- | *Default: ``PROJECT_VENV['<project>']='<project-dir>.venv'*
- | Each entry in the ``PROJECT_VENV`` array contains the directory name
- of a venv to be used for the project. The array index is the project
- name. Multiple projects can use the same venv if desired.
+Each entry in the ``PROJECT_VENV`` array contains the directory name
+of a venv to be used for the project. The array index is the project
+name. Multiple projects can use the same venv if desired.
::
PROJECT_VENV["glance"]=${GLANCE_DIR}.venv
- | *Default: ``ADDITIONAL_VENV_PACKAGES=""``*
- | A comma-separated list of additional packages to be installed into each
- venv. Often projects will not have certain packages listed in its
- ``requirements.txt`` file because they are 'optional' requirements,
- i.e. only needed for certain configurations. By default, the enabled
- databases will have their Python bindings added when they are enabled.
+``ADDITIONAL_VENV_PACKAGES`` is a comma-separated list of additional
+packages to be installed into each venv. Often projects will not have
+certain packages listed in its ``requirements.txt`` file because they
+are 'optional' requirements, i.e. only needed for certain
+configurations. By default, the enabled databases will have their
+Python bindings added when they are enabled.
-Enable Logging
---------------
+ ::
- | *Defaults: ``LOGFILE="" LOGDAYS=7 LOG_COLOR=True``*
- | By default ``stack.sh`` output is only written to the console
- where it 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``.
- |
+ ADDITIONAL_VENV_PACKAGES="python-foo, python-bar"
- ::
-
- LOGFILE=$DEST/logs/stack.sh.log
-
- Old log files are cleaned automatically if ``LOGDAYS`` is set to the
- number of days of old log files to keep.
-
- ::
-
- LOGDAYS=1
-
- The 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
-
-Logging the Service Output
---------------------------
-
- | *Default: ``LOGDIR=""``*
- | DevStack will log the stdout output of the services it starts.
- When using ``screen`` this logs the output in the screen windows
- to a file. Without ``screen`` this simply redirects stdout of
- the service process to a file in ``LOGDIR``.
- |
-
- ::
-
- LOGDIR=$DEST/logs
-
- *Note the use of ``DEST`` to locate the main install directory; this
- is why we suggest setting it in ``local.conf``.*
-
-Enabling Syslog
----------------
-
- | *Default: ``SYSLOG=False SYSLOG_HOST=$HOST_IP SYSLOG_PORT=516``*
- | Logging all services to a single syslog can be convenient. Enable
- syslogging by setting ``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
A clean install every time
--------------------------
- | *Default: ``RECLONE=""``*
- | By default ``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``.
- |
+By default ``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``.
::
@@ -281,13 +285,11 @@
Upgrade packages installed by pip
---------------------------------
- | *Default: ``PIP_UPGRADE=""``*
- | By default ``stack.sh`` only installs Python packages if no version
- is currently installed or the current version does not match a specified
- requirement. If ``PIP_UPGRADE`` is set to ``True`` then existing required
- Python packages will be upgraded to the most recent version that
- matches requirements.
- |
+By default ``stack.sh`` only installs Python packages if no version is
+currently installed or the current version does not match a specified
+requirement. If ``PIP_UPGRADE`` is set to ``True`` then existing
+required Python packages will be upgraded to the most recent version
+that matches requirements.
::
@@ -296,74 +298,69 @@
Swift
-----
- | Default: SWIFT_HASH=""
- | SWIFT_REPLICAS=1
- | SWIFT_DATA_DIR=$DEST/data/swift
+Swift is now used as the back-end for the S3-like object store. When
+enabled Nova's objectstore (``n-obj`` in ``ENABLED_SERVICES``) is
+automatically disabled. Enable Swift by adding it services to
+``ENABLED_SERVICES``
- | Swift is now used as the back-end for the S3-like object store.
- When enabled Nova's objectstore (n-obj in ENABLED_SERVICES) is
- automatically disabled. Enable Swift by adding it services to
- ENABLED_SERVICES: enable_service s-proxy s-object s-container
- s-account
+ ::
- Setting Swift's hash value is required and you will be prompted for
- it if Swift is enabled so just set it to something already:
+ enable_service s-proxy s-object s-container s-account
+
+Setting 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=66a3d6b56c1f479c8b4e70ab5c2000f5
- For 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.
+For 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=3
- The 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.
+The 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/swift
- *Note: 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.*
+*Note*: 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.
Service Catalog Backend
-----------------------
- | *Default: ``KEYSTONE_CATALOG_BACKEND=sql``*
- | DevStack uses Keystone's ``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:
- |
+By default DevStack uses Keystone's ``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
+with ``KEYSTONE_CATALOG_BACKEND``:
::
KEYSTONE_CATALOG_BACKEND=template
- DevStack's default configuration in ``sql`` mode is set in
- ``files/keystone_data.sh``
+DevStack's default configuration in ``sql`` mode is set in
+``files/keystone_data.sh``
Cinder
------
- | Default:
- | VOLUME_GROUP="stack-volumes" VOLUME_NAME_PREFIX="volume-" VOLUME_BACKING_FILE_SIZE=10250M
- | The logical volume group used to hold the Cinder-managed volumes
- is set by ``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``.
- |
+The logical volume group used to hold the Cinder-managed volumes is
+set by ``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``.
::
@@ -374,19 +371,23 @@
Multi-host DevStack
-------------------
- | *Default: ``MULTI_HOST=False``*
- | Running DevStack with multiple hosts requires a custom
- ``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.
- | **Master**
+Running DevStack with multiple hosts requires a custom ``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.
+Master
+~~~~~~
+
+Set ``MULTI_HOST`` to true
::
MULTI_HOST=True
- **Slave**
+Slave
+~~~~~
+
+Set the following options to point to the master
::
@@ -398,22 +399,19 @@
IP Version
----------
- | Default: ``IP_VERSION=4+6``
- | This setting can be used to configure DevStack to create either an IPv4,
- IPv6, or dual stack tenant data network by setting ``IP_VERSION`` to
- either ``IP_VERSION=4``, ``IP_VERSION=6``, or ``IP_VERSION=4+6``
- respectively. This functionality requires that the Neutron networking
- service is enabled by setting the following options:
- |
+``IP_VERSION`` can be used to configure DevStack to create either an
+IPv4, IPv6, or dual-stack tenant data-network by with either
+``IP_VERSION=4``, ``IP_VERSION=6``, or ``IP_VERSION=4+6``
+respectively. This functionality requires that the Neutron networking
+service is enabled by setting the following options:
::
disable_service n-net
enable_service q-svc q-agt q-dhcp q-l3
- | The following optional variables can be used to alter the default IPv6
- behavior:
- |
+The following optional variables can be used to alter the default IPv6
+behavior:
::
@@ -422,24 +420,28 @@
FIXED_RANGE_V6=fd$IPV6_GLOBAL_ID::/64
IPV6_PRIVATE_NETWORK_GATEWAY=fd$IPV6_GLOBAL_ID::1
- | *Note: ``FIXED_RANGE_V6`` and ``IPV6_PRIVATE_NETWORK_GATEWAY``
- can be configured with any valid IPv6 prefix. The default values make
- use of an auto-generated ``IPV6_GLOBAL_ID`` to comply with RFC 4193.*
- |
+*Note*: ``FIXED_RANGE_V6`` and ``IPV6_PRIVATE_NETWORK_GATEWAY`` can be
+configured with any valid IPv6 prefix. The default values make use of
+an auto-generated ``IPV6_GLOBAL_ID`` to comply with RFC4193.
- | Default: ``SERVICE_IP_VERSION=4``
- | This setting can be used to configure DevStack to enable services to
- operate over either IPv4 or IPv6, by setting ``SERVICE_IP_VERSION`` to
- either ``SERVICE_IP_VERSION=4`` or ``SERVICE_IP_VERSION=6`` respectively.
- When set to ``4`` devstack services will open listen sockets on 0.0.0.0
- and service endpoints will be registered using ``HOST_IP`` as the address.
- When set to ``6`` devstack services will open listen sockets on :: and
- service endpoints will be registered using ``HOST_IPV6`` as the address.
- The default value for this setting is ``4``. Dual-mode support, for
- example ``4+6`` is not currently supported.
- | The following optional variable can be used to alter the default IPv6
- address used:
- |
+Service Version
+~~~~~~~~~~~~~~~
+
+DevStack can enable service operation over either IPv4 or IPv6 by
+setting ``SERVICE_IP_VERSION`` to either ``SERVICE_IP_VERSION=4`` or
+``SERVICE_IP_VERSION=6`` respectively.
+
+When set to ``4`` devstack services will open listen sockets on
+``0.0.0.0`` and service endpoints will be registered using ``HOST_IP``
+as the address.
+
+When set to ``6`` devstack services will open listen sockets on ``::``
+and service endpoints will be registered using ``HOST_IPV6`` as the
+address.
+
+The default value for this setting is ``4``. Dual-mode support, for
+example ``4+6`` is not currently supported. ``HOST_IPV6`` can
+optionally be used to alter the default IPv6 address
::
diff --git a/doc/source/guides/multinode-lab.rst b/doc/source/guides/multinode-lab.rst
index 27d71f1..1530a84 100644
--- a/doc/source/guides/multinode-lab.rst
+++ b/doc/source/guides/multinode-lab.rst
@@ -175,15 +175,20 @@
SERVICE_TOKEN=xyzpdqlazydog
DATABASE_TYPE=mysql
SERVICE_HOST=192.168.42.11
- MYSQL_HOST=192.168.42.11
- RABBIT_HOST=192.168.42.11
- GLANCE_HOSTPORT=192.168.42.11:9292
- ENABLED_SERVICES=n-cpu,n-net,n-api,c-vol
+ MYSQL_HOST=$SERVICE_HOST
+ RABBIT_HOST=$SERVICE_HOST
+ GLANCE_HOSTPORT=$SERVICE_HOST:9292
+ ENABLED_SERVICES=n-cpu,n-net,n-api-meta,c-vol
NOVA_VNC_ENABLED=True
- NOVNCPROXY_URL="http://192.168.42.11:6080/vnc_auto.html"
+ NOVNCPROXY_URL="http://$SERVICE_HOST:6080/vnc_auto.html"
VNCSERVER_LISTEN=$HOST_IP
VNCSERVER_PROXYCLIENT_ADDRESS=$VNCSERVER_LISTEN
+**Note:** the ``n-api-meta`` service is a version of the api server
+that only serves the metadata service. It's needed because the
+computes created won't have a routing path to the metadata service on
+the controller.
+
Fire up OpenStack:
::
@@ -263,7 +268,7 @@
-----
Swift, OpenStack Object Storage, requires a significant amount of resources
-and is disabled by default in DevStack. The support in DevStack is geared
+and is disabled by default in DevStack. The support in DevStack is geared
toward a minimal installation but can be used for testing. To implement a
true multi-node test of swift, additional steps will be required. Enabling it is as
simple as enabling the ``swift`` service in ``local.conf``:
diff --git a/files/debs/n-cpu b/files/debs/n-cpu
index 5d5052a..ffc947a 100644
--- a/files/debs/n-cpu
+++ b/files/debs/n-cpu
@@ -5,3 +5,4 @@
sysfsutils
sg3-utils
python-guestfs # NOPRIME
+cryptsetup
diff --git a/files/rpms-suse/n-cpu b/files/rpms-suse/n-cpu
index 7040b84..b3a468d 100644
--- a/files/rpms-suse/n-cpu
+++ b/files/rpms-suse/n-cpu
@@ -4,3 +4,4 @@
open-iscsi
sysfsutils
sg3_utils
+cryptsetup
diff --git a/files/rpms/n-cpu b/files/rpms/n-cpu
index c1a8e8f..81278b3 100644
--- a/files/rpms/n-cpu
+++ b/files/rpms/n-cpu
@@ -4,4 +4,4 @@
genisoimage
sysfsutils
sg3_utils
-
+cryptsetup
diff --git a/functions b/functions
index 5bbe18f..4001e9d 100644
--- a/functions
+++ b/functions
@@ -10,6 +10,10 @@
# - ``GLANCE_HOSTPORT``
#
+# ensure we don't re-source this in the same environment
+[[ -z "$_DEVSTACK_FUNCTIONS" ]] || return 0
+declare -r _DEVSTACK_FUNCTIONS=1
+
# Include the common functions
FUNC_DIR=$(cd $(dirname "${BASH_SOURCE:-$0}") && pwd)
source ${FUNC_DIR}/functions-common
diff --git a/functions-common b/functions-common
index 60cf04c..a97cf0d 100644
--- a/functions-common
+++ b/functions-common
@@ -36,6 +36,10 @@
XTRACE=$(set +o | grep xtrace)
set +o xtrace
+# ensure we don't re-source this in the same environment
+[[ -z "$_DEVSTACK_FUNCTIONS_COMMON" ]] || return 0
+declare -r _DEVSTACK_FUNCTIONS_COMMON=1
+
# Global Config Variables
declare -A GITREPO
declare -A GITBRANCH
@@ -852,13 +856,18 @@
# Usage: _get_or_create_endpoint_with_interface <service> <interface> <url> <region>
function _get_or_create_endpoint_with_interface {
local endpoint_id
+ # TODO(dgonzalez): The check of the region name, as done in the grep
+ # statement below, exists only because keystone does currently
+ # not allow filtering the region name when listing endpoints. If keystone
+ # gets support for this, the check for the region name can be removed.
+ # Related bug in keystone: https://bugs.launchpad.net/keystone/+bug/1482772
endpoint_id=$(openstack endpoint list \
--os-url $KEYSTONE_SERVICE_URI_V3 \
--os-identity-api-version=3 \
--service $1 \
--interface $2 \
--region $4 \
- -c ID -f value)
+ -c ID -c Region -f value | grep $4 | cut -f 1 -d " ")
if [[ -z "$endpoint_id" ]]; then
# Creates new endpoint
endpoint_id=$(openstack endpoint create \
diff --git a/lib/apache b/lib/apache
index c7d69f2..a8e9bc5 100644
--- a/lib/apache
+++ b/lib/apache
@@ -11,7 +11,6 @@
# lib/apache exports the following functions:
#
# - install_apache_wsgi
-# - config_apache_wsgi
# - apache_site_config_for
# - enable_apache_site
# - disable_apache_site
diff --git a/lib/ceilometer b/lib/ceilometer
index ce93ebd..3df75b7 100644
--- a/lib/ceilometer
+++ b/lib/ceilometer
@@ -211,7 +211,6 @@
cp $CEILOMETER_DIR/etc/ceilometer/event_pipeline.yaml $CEILOMETER_CONF_DIR
cp $CEILOMETER_DIR/etc/ceilometer/api_paste.ini $CEILOMETER_CONF_DIR
cp $CEILOMETER_DIR/etc/ceilometer/event_definitions.yaml $CEILOMETER_CONF_DIR
- cp $CEILOMETER_DIR/etc/ceilometer/meters.yaml $CEILOMETER_CONF_DIR
cp $CEILOMETER_DIR/etc/ceilometer/gnocchi_archive_policy_map.yaml $CEILOMETER_CONF_DIR
cp $CEILOMETER_DIR/etc/ceilometer/gnocchi_resources.yaml $CEILOMETER_CONF_DIR
diff --git a/lib/ceph b/lib/ceph
index 6af4b3a..8e34aa4 100644
--- a/lib/ceph
+++ b/lib/ceph
@@ -326,7 +326,7 @@
sudo ceph -c ${CEPH_CONF_FILE} osd pool create ${CINDER_CEPH_POOL} ${CINDER_CEPH_POOL_PG} ${CINDER_CEPH_POOL_PGP}
sudo ceph -c ${CEPH_CONF_FILE} auth get-or-create client.${CINDER_CEPH_USER} \
mon "allow r" \
- osd "allow class-read object_prefix rbd_children, allow rwx pool=${CINDER_CEPH_POOL}, allow rwx pool=${NOVA_CEPH_POOL},allow rx pool=${GLANCE_CEPH_POOL}" | \
+ osd "allow class-read object_prefix rbd_children, allow rwx pool=${CINDER_CEPH_POOL}, allow rwx pool=${NOVA_CEPH_POOL},allow rwx pool=${GLANCE_CEPH_POOL}" | \
sudo tee ${CEPH_CONF_DIR}/ceph.client.${CINDER_CEPH_USER}.keyring
sudo chown ${STACK_USER}:$(id -g -n $whoami) ${CEPH_CONF_DIR}/ceph.client.${CINDER_CEPH_USER}.keyring
}
diff --git a/lib/glance b/lib/glance
index f200dca..b1b0f32 100644
--- a/lib/glance
+++ b/lib/glance
@@ -154,7 +154,10 @@
iniset $GLANCE_SWIFT_STORE_CONF ref1 user $SERVICE_TENANT_NAME:glance-swift
iniset $GLANCE_SWIFT_STORE_CONF ref1 key $SERVICE_PASSWORD
- iniset $GLANCE_SWIFT_STORE_CONF ref1 auth_address $KEYSTONE_SERVICE_URI/v2.0/
+ iniset $GLANCE_SWIFT_STORE_CONF ref1 auth_address $KEYSTONE_SERVICE_URI/v3
+ iniset $GLANCE_SWIFT_STORE_CONF ref1 user_domain_id default
+ iniset $GLANCE_SWIFT_STORE_CONF ref1 project_domain_id default
+ iniset $GLANCE_SWIFT_STORE_CONF ref1 auth_version 3
# commenting is not strictly necessary but it's confusing to have bad values in conf
inicomment $GLANCE_API_CONF glance_store swift_store_user
diff --git a/lib/infra b/lib/infra
index 3d68e45..eb8000e 100644
--- a/lib/infra
+++ b/lib/infra
@@ -30,8 +30,6 @@
# install_infra() - Collect source and prepare
function install_infra {
local PIP_VIRTUAL_ENV="$REQUIREMENTS_DIR/.venv"
- # bring down global requirements
- git_clone $REQUIREMENTS_REPO $REQUIREMENTS_DIR $REQUIREMENTS_BRANCH
[ ! -d $PIP_VIRTUAL_ENV ] && virtualenv $PIP_VIRTUAL_ENV
# We don't care about testing git pbr in the requirements venv.
PIP_VIRTUAL_ENV=$PIP_VIRTUAL_ENV pip_install -U pbr
diff --git a/lib/ironic b/lib/ironic
index 1323446..b3ad586 100644
--- a/lib/ironic
+++ b/lib/ironic
@@ -618,6 +618,7 @@
local node_id=$(ironic node-create $standalone_node_uuid\
--chassis_uuid $chassis_id \
--driver $IRONIC_DEPLOY_DRIVER \
+ --name node-$total_nodes \
-p cpus=$ironic_node_cpu\
-p memory_mb=$ironic_node_ram\
-p local_gb=$ironic_node_disk\
diff --git a/lib/neutron-legacy b/lib/neutron-legacy
index 4069439..59f37fd 100644
--- a/lib/neutron-legacy
+++ b/lib/neutron-legacy
@@ -730,7 +730,9 @@
function start_neutron_other_agents {
run_process q-dhcp "python $AGENT_DHCP_BINARY --config-file $NEUTRON_CONF --config-file=$Q_DHCP_CONF_FILE"
- if is_service_enabled q-vpn; then
+ if is_service_enabled neutron-vpnaas; then
+ : # Started by plugin
+ elif is_service_enabled q-vpn; then
run_process q-vpn "$AGENT_VPN_BINARY $(determine_config_files neutron-vpn-agent)"
else
run_process q-l3 "python $AGENT_L3_BINARY $(determine_config_files neutron-l3-agent)"
@@ -979,7 +981,7 @@
iniset $Q_DHCP_CONF_FILE DEFAULT use_namespaces $Q_USE_NAMESPACE
iniset $Q_DHCP_CONF_FILE DEFAULT root_helper "$Q_RR_COMMAND"
if [[ "$Q_USE_ROOTWRAP_DAEMON" == "True" ]]; then
- iniset $NEUTRON_TEST_CONFIG_FILE agent root_helper_daemon "$Q_RR_DAEMON_COMMAND"
+ iniset $Q_DHCP_CONF_FILE agent root_helper_daemon "$Q_RR_DAEMON_COMMAND"
fi
if ! is_service_enabled q-l3; then
diff --git a/lib/tempest b/lib/tempest
index ebed5ae..6863bae 100644
--- a/lib/tempest
+++ b/lib/tempest
@@ -82,6 +82,21 @@
IPV6_ENABLED=$(trueorfalse True IPV6_ENABLED)
IPV6_SUBNET_ATTRIBUTES_ENABLED=$(trueorfalse True IPV6_SUBNET_ATTRIBUTES_ENABLED)
+# Do we want to make a configuration where Tempest has admin on
+# the cloud. We don't always want to so that we can ensure Tempest
+# would work on a public cloud.
+TEMPEST_HAS_ADMIN=$(trueorfalse True TEMPEST_HAS_ADMIN)
+
+# Credential provider configuration option variables
+TEMPEST_ALLOW_TENANT_ISOLATION=${TEMPEST_ALLOW_TENANT_ISOLATION:-$TEMPEST_HAS_ADMIN}
+TEMPEST_USE_TEST_ACCOUNTS=$(trueorfalse False $TEMPEST_USE_TEST_ACCOUNTS)
+
+# The number of workers tempest is expected to be run with. This is used for
+# generating a accounts.yaml for running with test-accounts. This is also the
+# same variable that devstack-gate uses to specify the number of workers that
+# it will run tempest with
+TEMPEST_CONCURRENCY=${TEMPEST_CONCURRENCY:-$(nproc)}
+
# Functions
# ---------
@@ -174,11 +189,6 @@
password=${ADMIN_PASSWORD:-secrete}
- # Do we want to make a configuration where Tempest has admin on
- # the cloud. We don't always want to so that we can ensure Tempest
- # would work on a public cloud.
- TEMPEST_HAS_ADMIN=$(trueorfalse True TEMPEST_HAS_ADMIN)
-
# See ``lib/keystone`` where these users and tenants are set up
ADMIN_USERNAME=${ADMIN_USERNAME:-admin}
ADMIN_TENANT_NAME=${ADMIN_TENANT_NAME:-admin}
@@ -313,7 +323,7 @@
fi
if [ "$ENABLE_IDENTITY_V2" == "False" ]; then
# Only Identity v3 is available; then skip Identity API v2 tests
- iniset $TEMPEST_CONFIG identity-feature-enabled v2_api False
+ iniset $TEMPEST_CONFIG identity-feature-enabled api_v2 False
# In addition, use v3 auth tokens for running all Tempest tests
iniset $TEMPEST_CONFIG identity auth_version v3
else
@@ -335,11 +345,6 @@
# Image Features
iniset $TEMPEST_CONFIG image-feature-enabled deactivate_image True
- # Auth
- TEMPEST_ALLOW_TENANT_ISOLATION=${TEMPEST_ALLOW_TENANT_ISOLATION:-$TEMPEST_HAS_ADMIN}
- iniset $TEMPEST_CONFIG auth allow_tenant_isolation ${TEMPEST_ALLOW_TENANT_ISOLATION:-True}
- iniset $TEMPEST_CONFIG auth tempest_roles "Member"
-
# Compute
iniset $TEMPEST_CONFIG compute ssh_user ${DEFAULT_INSTANCE_USER:-cirros} # DEPRECATED
iniset $TEMPEST_CONFIG compute network_for_ssh $PRIVATE_NETWORK_NAME
@@ -457,6 +462,9 @@
fi
iniset $TEMPEST_CONFIG object-storage-feature-enabled discoverable_apis $object_storage_api_extensions
+ # Validation
+ iniset $TEMPEST_CONFIG validation run_validation ${TEMPEST_RUN_VALIDATION:-False}
+
# Volume
# TODO(dkranz): Remove the bootable flag when Juno is end of life.
iniset $TEMPEST_CONFIG volume-feature-enabled bootable True
@@ -542,6 +550,19 @@
sudo chown $STACK_USER $BOTO_CONF
fi
+ # Auth
+ iniset $TEMPEST_CONFIG auth tempest_roles "Member"
+ if [[ $TEMPEST_USE_TEST_ACCOUNTS == "True" ]]; then
+ if [[ $TEMPEST_HAS_ADMIN == "True" ]]; then
+ tempest-account-generator -c $TEMPEST_CONFIG --os-username $ADMIN_USERNAME --os-password $ADMIN_PASSWORD --os-tenant-name $ADMIN_TENANT_NAME -r $TEMPEST_CONCURRENCY --with-admin etc/accounts.yaml
+ else:
+ tempest-account-generator -c $TEMPEST_CONFIG --os-username $ADMIN_USERNAME --os-password $ADMIN_PASSWORD --os-tenant-name $ADMIN_TENANT_NAME -r $TEMPEST_CONCURRENCY etc/accounts.yaml
+ fi
+ iniset $TEMPEST_CONFIG auth allow_tenant_isolation False
+ iniset $TEMPEST_CONFIG auth test_accounts_file "etc/accounts.yaml"
+ else
+ iniset $TEMPEST_CONFIG auth allow_tenant_isolation ${TEMPEST_ALLOW_TENANT_ISOLATION:-True}
+ fi
# Restore IFS
IFS=$ifs
}
diff --git a/stack.sh b/stack.sh
index cfcf126..e924729 100755
--- a/stack.sh
+++ b/stack.sh
@@ -698,6 +698,11 @@
TRACK_DEPENDS=${TRACK_DEPENDS:-False}
+# Bring down global requirements before any use of pip_install. This is
+# necessary to ensure that the constraints file is in place before we
+# attempt to apply any constraints to pip installs.
+git_clone $REQUIREMENTS_REPO $REQUIREMENTS_DIR $REQUIREMENTS_BRANCH
+
# Install Python packages into a virtualenv so that we can track them
if [[ $TRACK_DEPENDS = True ]]; then
echo_summary "Installing Python packages into a virtualenv $DEST/.venv"
diff --git a/tools/worlddump.py b/tools/worlddump.py
index 926b4a1..1b337a9 100755
--- a/tools/worlddump.py
+++ b/tools/worlddump.py
@@ -85,6 +85,11 @@
print dfraw
+def ebtables_dump():
+ _header("EB Tables Dump")
+ _dump_cmd("sudo ebtables -L")
+
+
def iptables_dump():
tables = ['filter', 'nat', 'mangle']
_header("IP Tables Dump")
@@ -141,6 +146,7 @@
process_list()
network_dump()
iptables_dump()
+ ebtables_dump()
compute_consoles()
guru_meditation_report()