Merge "Docs: Use RFC5737 for Provider Networking"
diff --git a/doc/source/faq.rst b/doc/source/faq.rst
index 87f8469..b09d386 100644
--- a/doc/source/faq.rst
+++ b/doc/source/faq.rst
@@ -75,6 +75,21 @@
 Some people have success with bash 4 installed via homebrew to keep
 running tests on OS/X.
 
+Can I at least source ``openrc`` with ``zsh``?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+People have reported success with a special function to run ``openrc``
+through bash for this
+
+.. code-block:: bash
+
+   function sourceopenrc {
+       pushd ~/devstack >/dev/null
+       eval $(bash -c ". openrc $1 $2;env|sed -n '/OS_/ { s/^/export /;p}'")
+       popd >/dev/null
+   }
+
+
 Operation and Configuration
 ===========================
 
diff --git a/doc/source/index.rst b/doc/source/index.rst
index 6d0edb0..f15c306 100644
--- a/doc/source/index.rst
+++ b/doc/source/index.rst
@@ -10,6 +10,7 @@
    overview
    configuration
    plugins
+   plugin-registry
    faq
    changes
    hacking
diff --git a/doc/source/plugin-registry.rst b/doc/source/plugin-registry.rst
new file mode 100644
index 0000000..2dd70d8
--- /dev/null
+++ b/doc/source/plugin-registry.rst
@@ -0,0 +1,73 @@
+..
+  Note to reviewers: the intent of this file is to be easy for
+  community members to update. As such fast approving (single core +2)
+  is fine as long as you've identified that the plugin listed actually exists.
+
+==========================
+ DevStack Plugin Registry
+==========================
+
+Since we've created the external plugin mechanism, it's gotten used by
+a lot of projects. The following is a list of plugins that currently
+exist. Any project that wishes to list their plugin here is welcomed
+to.
+
+Official OpenStack Projects
+===========================
+
+The following are plugins that exist for official OpenStack projects.
+
++--------------------+-------------------------------------------+--------------------+
+|Plugin Name         |URL                                        |Comments            |
++--------------------+-------------------------------------------+--------------------+
+|magnum              |git://git.openstack.org/openstack/magnum   |                    |
++--------------------+-------------------------------------------+--------------------+
+|trove               |git://git.openstack.org/openstack/trove    |                    |
++--------------------+-------------------------------------------+--------------------+
+|zaqar               |git://git.openstack.org/openstack/zarar    |                    |
++--------------------+-------------------------------------------+--------------------+
+
+
+
+Drivers
+=======
+
++--------------------+-------------------------------------------------+------------------+
+|Plugin Name         |URL                                              |Comments          |
++--------------------+-------------------------------------------------+------------------+
+|dragonflow          |git://git.openstack.org/openstack/dragonflow     |[d1]_             |
++--------------------+-------------------------------------------------+------------------+
+|odl                 |git://git.openstack.org/openstack/networking-odl |[d2]_             |
++--------------------+-------------------------------------------------+------------------+
+
+.. [d1] demonstrates example of installing 3rd party SDN controller
+.. [d2] demonstrates a pretty advanced set of modes that that allow
+        one to run OpenDayLight either from a pre-existing install, or
+        also from source
+
+Alternate Configs
+=================
+
++-------------+------------------------------------------------------------+------------+
+| Plugin Name | URL                                                        | Comments   |
+|             |                                                            |            |
++-------------+------------------------------------------------------------+------------+
+|glusterfs    |git://git.openstack.org/stackforge/devstack-plugin-glusterfs|            |
++-------------+------------------------------------------------------------+------------+
+|             |                                                            |            |
++-------------+------------------------------------------------------------+------------+
+
+Additional Services
+===================
+
++-------------+------------------------------------------+------------+
+| Plugin Name | URL                                      | Comments   |
+|             |                                          |            |
++-------------+------------------------------------------+------------+
+|ec2-api      |git://git.openstack.org/stackforge/ec2api |[as1]_      |
++-------------+------------------------------------------+------------+
+|             |                                          |            |
++-------------+------------------------------------------+------------+
+
+.. [as1] first functional devstack plugin, hence why used in most of
+         the examples.
diff --git a/doc/source/plugins.rst b/doc/source/plugins.rst
index c4ed228..b166936 100644
--- a/doc/source/plugins.rst
+++ b/doc/source/plugins.rst
@@ -2,103 +2,21 @@
 Plugins
 =======
 
-DevStack has a couple of plugin mechanisms to allow easily adding
-support for additional projects and features.
+The OpenStack ecosystem is wide and deep, and only growing more so
+every day. The value of DevStack is that it's simple enough to
+understand what it's doing clearly. And yet we'd like to support as
+much of the OpenStack Ecosystem as possible. We do that with plugins.
 
-Extras.d Hooks
-==============
+DevStack plugins are bits of bash code that live outside the DevStack
+tree. They are called through a strong contract, so these plugins can
+be sure that they will continue to work in the future as DevStack
+evolves.
 
-These hooks are an extension of the service calls in
-``stack.sh`` at specific points in its run, plus ``unstack.sh`` and
-``clean.sh``. A number of the higher-layer projects are implemented in
-DevStack using this mechanism.
+Plugin Interface
+================
 
-The script in ``extras.d`` is expected to be mostly a dispatcher to
-functions in a ``lib/*`` script. The scripts are named with a
-zero-padded two digits sequence number prefix to control the order that
-the scripts are called, and with a suffix of ``.sh``. DevStack reserves
-for itself the sequence numbers 00 through 09 and 90 through 99.
-
-Below is a template that shows handlers for the possible command-line
-arguments:
-
-::
-
-    # template.sh - DevStack extras.d dispatch script template
-
-    # check for service enabled
-    if is_service_enabled template; then
-
-        if [[ "$1" == "source" ]]; then
-            # Initial source of lib script
-            source $TOP_DIR/lib/template
-        fi
-
-        if [[ "$1" == "stack" && "$2" == "pre-install" ]]; then
-            # Set up system services
-            echo_summary "Configuring system services Template"
-            install_package cowsay
-
-        elif [[ "$1" == "stack" && "$2" == "install" ]]; then
-            # Perform installation of service source
-            echo_summary "Installing Template"
-            install_template
-
-        elif [[ "$1" == "stack" && "$2" == "post-config" ]]; then
-            # Configure after the other layer 1 and 2 services have been configured
-            echo_summary "Configuring Template"
-            configure_template
-
-        elif [[ "$1" == "stack" && "$2" == "extra" ]]; then
-            # Initialize and start the template service
-            echo_summary "Initializing Template"
-            ##init_template
-        fi
-
-        if [[ "$1" == "unstack" ]]; then
-            # Shut down template services
-            # no-op
-            :
-        fi
-
-        if [[ "$1" == "clean" ]]; then
-            # Remove state and transient data
-            # Remember clean.sh first calls unstack.sh
-            # no-op
-            :
-        fi
-    fi
-
-The arguments are:
-
--  **source** - Called by each script that utilizes ``extras.d`` hooks;
-   this replaces directly sourcing the ``lib/*`` script.
--  **stack** - Called by ``stack.sh`` three times for different phases
-   of its run:
-
-   -  **pre-install** - Called after system (OS) setup is complete and
-      before project source is installed.
-   -  **install** - Called after the layer 1 and 2 projects source and
-      their dependencies have been installed.
-   -  **post-config** - Called after the layer 1 and 2 services have
-      been configured. All configuration files for enabled services
-      should exist at this point.
-   -  **extra** - Called near the end after layer 1 and 2 services have
-      been started. This is the existing hook and has not otherwise
-      changed.
-
--  **unstack** - Called by ``unstack.sh`` before other services are shut
-   down.
--  **clean** - Called by ``clean.sh`` before other services are cleaned,
-   but after ``unstack.sh`` has been called.
-
-
-Externally Hosted Plugins
-=========================
-
-Based on the extras.d hooks, DevStack supports a standard mechansim
-for including plugins from external repositories. The plugin interface
-assumes the following:
+DevStack supports a standard mechansim for including plugins from
+external repositories. The plugin interface assumes the following:
 
 An external git repository that includes a ``devstack/`` top level
 directory. Inside this directory there can be 2 files.
@@ -118,11 +36,10 @@
   default value only if the variable is unset or empty; e.g. in bash
   syntax ``FOO=${FOO:-default}``.
 
-- ``plugin.sh`` - the actual plugin. It will be executed by devstack
-  during it's run. The run order will be done in the registration
-  order for these plugins, and will occur immediately after all in
-  tree extras.d dispatch at the phase in question.  The plugin.sh
-  looks like the extras.d dispatcher above.
+- ``plugin.sh`` - the actual plugin. It is executed by devstack at
+  well defined points during a ``stack.sh`` run. The plugin.sh
+  internal structure is discussed bellow.
+
 
 Plugins are registered by adding the following to the localrc section
 of ``local.conf``.
@@ -141,49 +58,121 @@
 
   enable_plugin ec2api git://git.openstack.org/stackforge/ec2api
 
-Plugins for gate jobs
----------------------
+plugin.sh contract
+==================
 
-All OpenStack plugins that wish to be used as gate jobs need to exist
-in OpenStack's gerrit. Both ``openstack`` namespace and ``stackforge``
-namespace are fine. This allows testing of the plugin as well as
-provides network isolation against upstream git repository failures
-(which we see often enough to be an issue).
+``plugin.sh`` is a bash script that will be called at specific points
+during ``stack.sh``, ``unstack.sh``, and ``clean.sh``. It will be
+called in the following way::
 
-Ideally plugins will be implemented as ``devstack`` directory inside
-the project they are testing. For example, the stackforge/ec2-api
-project has it's pluggin support in it's tree.
+  source $PATH/TO/plugin.sh <mode> [phase]
 
-In the cases where there is no "project tree" per say (like
-integrating a backend storage configuration such as ceph or glusterfs)
-it's also allowed to build a dedicated
-``stackforge/devstack-plugin-FOO`` project to house the plugin.
+``mode`` can be thought of as the major mode being called, currently
+one of: ``stack``, ``unstack``, ``clean``. ``phase`` is used by modes
+which have multiple points during their run where it's necessary to
+be able to execute code. All existing ``mode`` and ``phase`` points
+are considered **strong contracts** and won't be removed without a
+reasonable deprecation period. Additional new ``mode`` or ``phase``
+points may be added at any time if we discover we need them to support
+additional kinds of plugins in devstack.
 
-Note jobs must not require cloning of repositories during tests.
-Tests must list their repository in the ``PROJECTS`` variable for
-`devstack-gate
-<https://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/devstack-vm-gate-wrap.sh>`_
-for the repository to be available to the test.  Further information
-is provided in the project creator's guide.
+The current full list of ``mode`` and ``phase`` are:
 
-Hypervisor
-==========
+-  **stack** - Called by ``stack.sh`` four times for different phases
+   of its run:
 
-Hypervisor plugins are fairly new and condense most hypervisor
-configuration into one place.
+   -  **pre-install** - Called after system (OS) setup is complete and
+      before project source is installed.
+   -  **install** - Called after the layer 1 and 2 projects source and
+      their dependencies have been installed.
+   -  **post-config** - Called after the layer 1 and 2 services have
+      been configured. All configuration files for enabled services
+      should exist at this point.
+   -  **extra** - Called near the end after layer 1 and 2 services have
+      been started.
 
-The initial plugin implemented was for Docker support and is a useful
-template for the required support. Plugins are placed in
-``lib/nova_plugins`` and named ``hypervisor-<name>`` where ``<name>`` is
-the value of ``VIRT_DRIVER``. Plugins must define the following
-functions:
+-  **unstack** - Called by ``unstack.sh`` before other services are shut
+   down.
+-  **clean** - Called by ``clean.sh`` before other services are cleaned,
+   but after ``unstack.sh`` has been called.
 
--  ``install_nova_hypervisor`` - install any external requirements
--  ``configure_nova_hypervisor`` - make configuration changes, including
-   those to other services
--  ``start_nova_hypervisor`` - start any external services
--  ``stop_nova_hypervisor`` - stop any external services
--  ``cleanup_nova_hypervisor`` - remove transient data and cache
+Example plugin
+====================
+
+An example plugin would look something as follows.
+
+``devstack/settings``::
+
+    # settings file for template
+  enable_service template
+
+
+``devstack/plugin.sh``::
+
+    # plugin.sh - DevStack plugin.sh dispatch script template
+
+    function install_template {
+        ...
+    }
+
+    function init_template {
+        ...
+    }
+
+    function configure_template {
+        ...
+    }
+
+    # check for service enabled
+    if is_service_enabled template; then
+
+        if [[ "$1" == "stack" && "$2" == "pre-install" ]]; then
+            # Set up system services
+            echo_summary "Configuring system services Template"
+            install_package cowsay
+
+        elif [[ "$1" == "stack" && "$2" == "install" ]]; then
+            # Perform installation of service source
+            echo_summary "Installing Template"
+            install_template
+
+        elif [[ "$1" == "stack" && "$2" == "post-config" ]]; then
+            # Configure after the other layer 1 and 2 services have been configured
+            echo_summary "Configuring Template"
+            configure_template
+
+        elif [[ "$1" == "stack" && "$2" == "extra" ]]; then
+            # Initialize and start the template service
+            echo_summary "Initializing Template"
+            init_template
+        fi
+
+        if [[ "$1" == "unstack" ]]; then
+            # Shut down template services
+            # no-op
+            :
+        fi
+
+        if [[ "$1" == "clean" ]]; then
+            # Remove state and transient data
+            # Remember clean.sh first calls unstack.sh
+            # no-op
+            :
+        fi
+    fi
+
+Plugin Execution Order
+======================
+
+Plugins are run after in tree services at each of the stages
+above. For example, if you need something to happen before Keystone
+starts, you should do that at the ``post-config`` phase.
+
+Multiple plugins can be specified in your ``local.conf``. When that
+happens the plugins will be executed **in order** at each phase. This
+allows plugins to conceptually depend on each other through
+documenting to the user the order they must be declared. A formal
+dependency mechanism is beyond the scope of the current work.
 
 System Packages
 ===============
@@ -205,3 +194,47 @@
 
 - ``./devstack/files/rpms-suse/$plugin_name`` - Packages to install when
   running on SUSE Linux or openSUSE.
+
+
+Using Plugins in the OpenStack Gate
+===================================
+
+For everyday use, DevStack plugins can exist in any git tree that's
+accessible on the internet. However, when using DevStack plugins in
+the OpenStack gate, they must live in projects in OpenStack's
+gerrit. Both ``openstack`` namespace and ``stackforge`` namespace are
+fine. This allows testing of the plugin as well as provides network
+isolation against upstream git repository failures (which we see often
+enough to be an issue).
+
+Ideally a plugin will be included within the ``devstack`` directory of
+the project they are being tested. For example, the stackforge/ec2-api
+project has its pluggin support in its own tree.
+
+However, some times a DevStack plugin might be used solely to
+configure a backend service that will be used by the rest of
+OpenStack, so there is no "project tree" per say. Good examples
+include: integration of back end storage (e.g. ceph or glusterfs),
+integration of SDN controllers (e.g. ovn, OpenDayLight), or
+integration of alternate RPC systems (e.g. zmq, qpid). In these cases
+the best practice is to build a dedicated
+``stackforge/devstack-plugin-FOO`` project.
+
+To enable a plugin to be used in a gate job, the following lines will
+be needed in your project.yaml definition::
+
+  # Because we are testing a non standard project, add the
+  # our project repository. This makes zuul do the right
+  # reference magic for testing changes.
+  export PROJECTS="stackforge/ec2-api $PROJECTS"
+
+  # note the actual url here is somewhat irrelevant because it
+  # caches in nodepool, however make it a valid url for
+  # documentation purposes.
+  export DEVSTACK_LOCAL_CONFIG="enable_plugin ec2-api git://git.openstack.org/stackforge/ec2-api"
+
+See Also
+========
+
+For additional inspiration on devstack plugins you can check out the
+`Plugin Registry <plugin-registry.html>`_.
diff --git a/exercises/sahara.sh b/exercises/sahara.sh
index 2589e28..8cad945 100755
--- a/exercises/sahara.sh
+++ b/exercises/sahara.sh
@@ -35,7 +35,13 @@
 
 is_service_enabled sahara || exit 55
 
-$CURL_GET http://$SERVICE_HOST:8386/ 2>/dev/null | grep -q 'Auth' || die $LINENO "Sahara API isn't functioning!"
+if is_ssl_enabled_service "sahara" || is_service_enabled tls-proxy; then
+    SAHARA_SERVICE_PROTOCOL="https"
+fi
+
+SAHARA_SERVICE_PROTOCOL=${SAHARA_SERVICE_PROTOCOL:-$SERVICE_PROTOCOL}
+
+$CURL_GET $SAHARA_SERVICE_PROTOCOL://$SERVICE_HOST:8386/ 2>/dev/null | grep -q 'Auth' || die $LINENO "Sahara API isn't functioning!"
 
 set +o xtrace
 echo "*********************************************************************"
diff --git a/files/rpms/general b/files/rpms/general
index 67b084e..c3f3de8 100644
--- a/files/rpms/general
+++ b/files/rpms/general
@@ -28,3 +28,4 @@
 java-1.7.0-openjdk-headless  # NOPRIME rhel7
 java-1.8.0-openjdk-headless  # NOPRIME f21,f22
 pyOpenSSL # version in pip uses too much memory
+iptables-services  # NOPRIME f21,f22
diff --git a/functions-common b/functions-common
index 3a2f5f7..c85052d 100644
--- a/functions-common
+++ b/functions-common
@@ -43,6 +43,25 @@
 
 TRACK_DEPENDS=${TRACK_DEPENDS:-False}
 
+# Save these variables to .stackenv
+STACK_ENV_VARS="BASE_SQL_CONN DATA_DIR DEST ENABLED_SERVICES HOST_IP \
+    KEYSTONE_AUTH_PROTOCOL KEYSTONE_AUTH_URI KEYSTONE_SERVICE_URI \
+    LOGFILE OS_CACERT SERVICE_HOST SERVICE_PROTOCOL STACK_USER TLS_IP"
+
+
+# Saves significant environment variables to .stackenv for later use
+# Refers to a lot of globals, only TOP_DIR and STACK_ENV_VARS are required to
+# function, the rest are simply saved and do not cause problems if they are undefined.
+# save_stackenv [tag]
+function save_stackenv {
+    local tag=${1:-""}
+    # Save some values we generated for later use
+    time_stamp=$(date "+$TIMESTAMP_FORMAT")
+    echo "# $time_stamp $tag" >$TOP_DIR/.stackenv
+    for i in $STACK_ENV_VARS; do
+        echo $i=${!i} >>$TOP_DIR/.stackenv
+    done
+}
 
 # Normalize config values to True or False
 # Accepts as False: 0 no No NO false False FALSE
@@ -68,6 +87,7 @@
     [[ -v "$1" ]]
 }
 
+
 # Control Functions
 # =================
 
diff --git a/inc/python b/inc/python
index 3d329b5..e3c5e61 100644
--- a/inc/python
+++ b/inc/python
@@ -219,15 +219,15 @@
         if [[ "$REQUIREMENTS_MODE" == "soft" ]]; then
             if is_in_projects_txt $project_dir; then
                 (cd $REQUIREMENTS_DIR; \
-                    python update.py $project_dir)
+                    ./.venv/bin/python update.py $project_dir)
             else
                 # soft update projects not found in requirements project.txt
                 (cd $REQUIREMENTS_DIR; \
-                    python update.py -s $project_dir)
+                    ./.venv/bin/python update.py -s $project_dir)
             fi
         else
             (cd $REQUIREMENTS_DIR; \
-                python update.py $project_dir)
+                ./.venv/bin/python update.py $project_dir)
         fi
     fi
 
diff --git a/lib/ceilometer b/lib/ceilometer
index 90c7705..d7888d9 100644
--- a/lib/ceilometer
+++ b/lib/ceilometer
@@ -334,12 +334,15 @@
         pip_install_gr pymongo
     fi
 
-    if [[ "$VIRT_DRIVER" = 'libvirt' ]]; then
-        pip_install_gr libvirt-python
-    fi
+    # Only install virt drivers if we're running nova compute
+    if is_service_enabled n-cpu ; then
+        if [[ "$VIRT_DRIVER" = 'libvirt' ]]; then
+            pip_install_gr libvirt-python
+        fi
 
-    if [[ "$VIRT_DRIVER" = 'vsphere' ]]; then
-        pip_instal_gr oslo.vmware
+        if [[ "$VIRT_DRIVER" = 'vsphere' ]]; then
+            pip_instal_gr oslo.vmware
+        fi
     fi
 
     if [ "$CEILOMETER_BACKEND" = 'es' ] ; then
@@ -363,10 +366,7 @@
         git_clone_by_name "ceilometermiddleware"
         setup_dev_lib "ceilometermiddleware"
     else
-        # BUG: this should be a pip_install_gr except it was never
-        # included in global-requirements. Needs to be fixed by
-        # https://bugs.launchpad.net/ceilometer/+bug/1441655
-        pip_install ceilometermiddleware
+        pip_install_gr ceilometermiddleware
     fi
 }
 
diff --git a/lib/cinder b/lib/cinder
index ade3b82..8117447 100644
--- a/lib/cinder
+++ b/lib/cinder
@@ -66,6 +66,10 @@
 CINDER_SERVICE_PORT_INT=${CINDER_SERVICE_PORT_INT:-18776}
 CINDER_SERVICE_PROTOCOL=${CINDER_SERVICE_PROTOCOL:-$SERVICE_PROTOCOL}
 
+# What type of LVM device should Cinder use for LVM backend
+# Defaults to default, which is thick, the other valid choice
+# is thin, which as the name implies utilizes lvm thin provisioning.
+CINDER_LVM_TYPE=${CINDER_LVM_TYPE:-default}
 
 # Default backends
 # The backend format is type:name where type is one of the supported backend
diff --git a/lib/cinder_backends/lvm b/lib/cinder_backends/lvm
index 35ad209..411b82c 100644
--- a/lib/cinder_backends/lvm
+++ b/lib/cinder_backends/lvm
@@ -51,6 +51,7 @@
     iniset $CINDER_CONF $be_name volume_driver "cinder.volume.drivers.lvm.LVMVolumeDriver"
     iniset $CINDER_CONF $be_name volume_group $VOLUME_GROUP_NAME-$be_name
     iniset $CINDER_CONF $be_name iscsi_helper "$CINDER_ISCSI_HELPER"
+    iniset $CINDER_CONF $be_name lvm_type "$CINDER_LVM_TYPE"
 
     if [[ "$CINDER_SECURE_DELETE" == "False" ]]; then
         iniset $CINDER_CONF $be_name volume_clear none
diff --git a/lib/infra b/lib/infra
index c825b4e..585e9b4 100644
--- a/lib/infra
+++ b/lib/infra
@@ -29,8 +29,13 @@
 
 # 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
+    PIP_VIRTUAL_ENV=$PIP_VIRTUAL_ENV pip_install $REQUIREMENTS_DIR
 
     # Install pbr
     if use_library_from_git "pbr"; then
diff --git a/lib/oslo b/lib/oslo
index be26668..554bec8 100644
--- a/lib/oslo
+++ b/lib/oslo
@@ -37,6 +37,7 @@
 GITDIR["oslo.policy"]=$DEST/oslo.policy
 GITDIR["oslo.rootwrap"]=$DEST/oslo.rootwrap
 GITDIR["oslo.serialization"]=$DEST/oslo.serialization
+GITDIR["oslo.service"]=$DEST/oslo.service
 GITDIR["oslo.utils"]=$DEST/oslo.utils
 GITDIR["oslo.versionedobjects"]=$DEST/oslo.versionedobjects
 GITDIR["oslo.vmware"]=$DEST/oslo.vmware
@@ -76,6 +77,7 @@
     _do_install_oslo_lib "oslo.policy"
     _do_install_oslo_lib "oslo.rootwrap"
     _do_install_oslo_lib "oslo.serialization"
+    _do_install_oslo_lib "oslo.service"
     _do_install_oslo_lib "oslo.utils"
     _do_install_oslo_lib "oslo.versionedobjects"
     _do_install_oslo_lib "oslo.vmware"
diff --git a/lib/tempest b/lib/tempest
index c4ae05f..9fba0aa 100644
--- a/lib/tempest
+++ b/lib/tempest
@@ -329,6 +329,7 @@
     if [[ ! -z "$TEMPEST_HTTP_IMAGE" ]]; then
         iniset $TEMPEST_CONFIG image http_image $TEMPEST_HTTP_IMAGE
     fi
+    iniset $TEMPEST_CONFIG image-feature-enabled deactivate_image true
 
     # Image Features
     iniset $TEMPEST_CONFIG image-feature-enabled deactivate_image True
@@ -451,6 +452,9 @@
     iniset $TEMPEST_CONFIG object-storage-feature-enabled discoverable_apis $object_storage_api_extensions
 
     # Volume
+    # TODO(dkranz): Remove the bootable flag when Juno is end of life.
+    iniset $TEMPEST_CONFIG volume-feature-enabled bootable True
+
     local volume_api_extensions=${VOLUME_API_EXTENSIONS:-"all"}
     if [[ ! -z "$DISABLE_VOLUME_API_EXTENSIONS" ]]; then
         # Enabled extensions are either the ones explicitly specified or those available on the API endpoint
diff --git a/stack.sh b/stack.sh
index 0c01165..0d9d836 100755
--- a/stack.sh
+++ b/stack.sh
@@ -669,6 +669,9 @@
     fi
 fi
 
+# Save configuration values
+save_stackenv $LINENO
+
 
 # Install Packages
 # ================
@@ -950,6 +953,9 @@
 # Initialize the directory for service status check
 init_service_check
 
+# Save configuration values
+save_stackenv $LINENO
+
 
 # Start Services
 # ==============
@@ -1287,12 +1293,7 @@
 
 
 # Save some values we generated for later use
-CURRENT_RUN_TIME=$(date "+$TIMESTAMP_FORMAT")
-echo "# $CURRENT_RUN_TIME" >$TOP_DIR/.stackenv
-for i in BASE_SQL_CONN ENABLED_SERVICES HOST_IP LOGFILE \
-    SERVICE_HOST SERVICE_PROTOCOL STACK_USER TLS_IP KEYSTONE_AUTH_PROTOCOL OS_CACERT; do
-    echo $i=${!i} >>$TOP_DIR/.stackenv
-done
+save_stackenv
 
 # Write out a clouds.yaml file
 # putting the location into a variable to allow for easier refactoring later
diff --git a/stackrc b/stackrc
index c16a999..1ac1338 100644
--- a/stackrc
+++ b/stackrc
@@ -382,6 +382,10 @@
 GITREPO["oslo.serialization"]=${OSLOSERIALIZATION_REPO:-${GIT_BASE}/openstack/oslo.serialization.git}
 GITBRANCH["oslo.serialization"]=${OSLOSERIALIZATION_BRANCH:-master}
 
+# oslo.service
+GITREPO["oslo.service"]=${OSLOSERVICE_REPO:-${GIT_BASE}/openstack/oslo.service.git}
+GITBRANCH["oslo.service"]=${OSLOSERVICE_BRANCH:-master}
+
 # oslo.utils
 GITREPO["oslo.utils"]=${OSLOUTILS_REPO:-${GIT_BASE}/openstack/oslo.utils.git}
 GITBRANCH["oslo.utils"]=${OSLOUTILS_BRANCH:-master}
diff --git a/tests/test_libs_from_pypi.sh b/tests/test_libs_from_pypi.sh
index 2f0b1fe..fc65967 100755
--- a/tests/test_libs_from_pypi.sh
+++ b/tests/test_libs_from_pypi.sh
@@ -39,7 +39,7 @@
 ALL_LIBS+=" python-openstackclient oslo.rootwrap oslo.i18n"
 ALL_LIBS+=" python-ceilometerclient oslo.utils python-swiftclient"
 ALL_LIBS+=" python-neutronclient tooz ceilometermiddleware oslo.policy"
-ALL_LIBS+=" debtcollector os-brick automaton futurist"
+ALL_LIBS+=" debtcollector os-brick automaton futurist oslo.service"
 
 # Generate the above list with
 # echo ${!GITREPO[@]}
diff --git a/tools/fixup_stuff.sh b/tools/fixup_stuff.sh
index 31258d1..4fff57f 100755
--- a/tools/fixup_stuff.sh
+++ b/tools/fixup_stuff.sh
@@ -126,6 +126,9 @@
         # [4] http://docs.openstack.org/developer/devstack/guides/neutron.html
         if is_package_installed firewalld; then
             sudo systemctl disable firewalld
+            # The iptables service files are no longer included by default,
+            # at least on a baremetal Fedora 21 Server install.
+            install_package iptables-services
             sudo systemctl enable iptables
             sudo systemctl stop firewalld
             sudo systemctl start iptables