diff --git a/clean.sh b/clean.sh
index 0641bff..452df02 100755
--- a/clean.sh
+++ b/clean.sh
@@ -95,6 +95,7 @@
 cleanup_nova
 cleanup_neutron
 cleanup_swift
+cleanup_horizon
 
 if is_service_enabled ldap; then
     cleanup_ldap
diff --git a/doc/source/assets/images/screen_session_1.png b/doc/source/assets/images/screen_session_1.png
new file mode 100644
index 0000000..6ad6752
--- /dev/null
+++ b/doc/source/assets/images/screen_session_1.png
Binary files differ
diff --git a/doc/source/development.rst b/doc/source/development.rst
new file mode 100644
index 0000000..776ac6c
--- /dev/null
+++ b/doc/source/development.rst
@@ -0,0 +1,140 @@
+==========================
+ Developing with Devstack
+==========================
+
+Now that you have your nifty DevStack up and running, what can you do
+with it?
+
+Inspecting Services
+===================
+
+By default most services in DevStack are running in a `screen
+<https://www.gnu.org/software/screen/manual/screen.html>`_
+session.
+
+.. code-block:: bash
+
+   os3:~> screen -list
+   There is a screen on:
+        28994.stack	(08/10/2016 09:01:33 PM)	(Detached)
+   1 Socket in /var/run/screen/S-sdague.
+
+You can attach to this screen session using ``screen -r`` which gives
+you a view of the services in action.
+
+.. image:: assets/images/screen_session_1.png
+   :width: 100%
+
+Basic Screen Commands
+---------------------
+
+The following minimal commands will be useful to using screen:
+
+* ``ctrl-a n`` - go to next window. Next is assumed to be right of
+  current window.
+* ``ctrl-a p`` - go to previous window. Previous is assumed to be left
+  of current window.
+* ``ctrl-a [`` - entry copy/scrollback mode. This allows you to
+  navigate back through the logs with the up arrow.
+* ``ctrl-a d`` - detach from screen. Gets you back to a normal
+  terminal, while leaving everything running.
+
+For more about using screen, see the excellent `screen manual
+<https://www.gnu.org/software/screen/manual/screen.html>`_.
+
+Patching a Service
+==================
+
+If you want to make a quick change to a running service the easiest
+way to do this is:
+
+* attach to screen
+* navigate to the window in question
+* ``ctrl-c`` to kill the service
+* make appropriate changes to the code
+* ``up arrow`` in the screen window to display the command used to run
+  that service
+* ``enter`` to restart the service
+
+This works for services, except those running under Apache (currently
+just ``keystone`` by default).
+
+.. warning::
+
+   All changes you are making are in checked out git trees that
+   DevStack thinks it has full control over. Uncommitted work, or
+   work committed to the master branch, may be overwritten during
+   subsequent DevStack runs.
+
+Testing a Patch Series
+======================
+
+When testing a larger set of patches, or patches that will impact more
+than one service within a project, it is often less confusing to use
+custom git locations, and make all your changes in a dedicated git
+tree.
+
+In your ``local.conf`` you can add ``**_REPO``, ``**_BRANCH`` for most projects
+to use a custom git tree instead of the default upstream ones.
+
+For instance:
+
+.. code-block:: bash
+
+   [[local|localrc]]
+   NOVA_REPO=/home/sdague/nova
+   NOVA_BRANCH=fold_disk_config
+
+Will use a custom git tree and branch when doing any devstack
+operations, such as ``stack.sh``.
+
+When testing complicated changes committing to these trees, then doing
+``./unstack.sh && ./stack.sh`` is often a valuable way to
+iterate. This does take longer per iteration than direct patching, as
+the whole devstack needs to rebuild.
+
+You can use this same approach to test patches that are up for review
+in gerrit by using the ref name that gerrit assigns to each change.
+
+.. code-block:: bash
+
+   [[local|localrc]]
+   NOVA_BRANCH=refs/changes/10/353710/1
+
+
+Testing Changes to Apache Based Services
+========================================
+
+When testing changes to Apache based services, such as ``keystone``,
+you can either use the Testing a Patch Series approach above, or make
+changes in the code tree and issue an apache restart.
+
+
+Testing Changes to Libraries
+============================
+
+When testing changes to libraries consumed by OpenStack services (such
+as oslo or any of the python-fooclient libraries) things are a little
+more complicated. By default we only test with released versions of
+these libraries that are on pypi.
+
+You must first override this with the setting ``LIBS_FROM_GIT``. This
+will enable your DevStack with the git version of that library instead
+of the released version.
+
+After that point you can also specify ``**_REPO``, ``**_BRANCH`` to use
+your changes instead of just upstream master.
+
+.. code-block:: bash
+
+   [[local|localrc]]
+   LIBS_FROM_GIT=oslo.policy
+   OSLOPOLICY_REPO=/home/sdague/oslo.policy
+   OSLOPOLICY_BRANCH=better_exception
+
+Because libraries are used by many services, library changes really
+need to go through a full ``./unstack.sh && ./stack.sh`` to see your
+changes in action.
+
+To figure out the repo / branch names for every library that's
+supported, you'll need to read the devstack source.
diff --git a/doc/source/guides.rst b/doc/source/guides.rst
new file mode 100644
index 0000000..c2c7b91
--- /dev/null
+++ b/doc/source/guides.rst
@@ -0,0 +1,68 @@
+Guides
+======
+
+.. warning::
+
+   The guides are point in time contributions, and may not always be
+   up to date with the latest work in devstack.
+
+Walk through various setups used by stackers
+
+.. toctree::
+   :glob:
+   :maxdepth: 1
+
+   guides/single-vm
+   guides/single-machine
+   guides/lxc
+   guides/multinode-lab
+   guides/neutron
+   guides/devstack-with-nested-kvm
+   guides/nova
+   guides/devstack-with-lbaas-v2
+
+All-In-One Single VM
+--------------------
+
+Run :doc:`OpenStack in a VM <guides/single-vm>`. The VMs launched in your cloud will be slow as
+they are running in QEMU (emulation), but it is useful if you don't have
+spare hardware laying around. :doc:`[Read] <guides/single-vm>`
+
+All-In-One Single Machine
+-------------------------
+
+Run :doc:`OpenStack on dedicated hardware <guides/single-machine>`  This can include a
+server-class machine or a laptop at home.
+:doc:`[Read] <guides/single-machine>`
+
+All-In-One LXC Container
+-------------------------
+
+Run :doc:`OpenStack in a LXC container <guides/lxc>`. Beneficial for intermediate
+and advanced users. The VMs launched in this cloud will be fully accelerated but
+not all OpenStack features are supported. :doc:`[Read] <guides/lxc>`
+
+Multi-Node Lab
+--------------
+
+Setup a :doc:`multi-node cluster <guides/multinode-lab>` with dedicated VLANs for VMs & Management.
+:doc:`[Read] <guides/multinode-lab>`
+
+DevStack with Neutron Networking
+--------------------------------
+
+Building a DevStack cluster with :doc:`Neutron Networking <guides/neutron>`.
+This guide is meant for building lab environments with a dedicated
+control node and multiple compute nodes.
+
+DevStack with KVM-based Nested Virtualization
+---------------------------------------------
+
+Procedure to setup :doc:`DevStack with KVM-based Nested Virtualization
+<guides/devstack-with-nested-kvm>`. With this setup, Nova instances
+will be more performant than with plain QEMU emulation.
+
+Nova and devstack
+--------------------------------
+
+Guide to working with nova features :doc:`Nova and devstack <guides/nova>`.
diff --git a/doc/source/index.rst b/doc/source/index.rst
index 68ec174..435011b 100644
--- a/doc/source/index.rst
+++ b/doc/source/index.rst
@@ -1,163 +1,135 @@
-DevStack
-========
+.. Documentation Architecture for the devstack docs.
+
+   It is really easy for online docs to meander over time as people
+   attempt to add the small bit of additional information they think
+   people need, into an existing information architecture. In order to
+   prevent that we need to be a bit strict as to what's on this front
+   page.
+
+   This should *only* be the quick start narrative. Which should end
+   with 2 sections: what you can do with devstack once it's set up,
+   and how to go beyond this setup. Both should be a set of quick
+   links to other documents to let people explore from there.
+
+==========
+ DevStack
+==========
 
 .. image:: assets/images/logo-blue.png
 
 DevStack is a series of extensible scripts used to quickly bring up a
-complete OpenStack environment.  It is used interactively as a
-development environment and as the basis for much of the OpenStack
-project's functional testing.
+complete OpenStack environment based on the latest versions of
+everything from git master.  It is used interactively as a development
+environment and as the basis for much of the OpenStack project's
+functional testing.
 
 The source is available at
 `<https://git.openstack.org/cgit/openstack-dev/devstack>`__.
 
-.. toctree::
-   :glob:
-   :maxdepth: 1
+.. warning::
 
-   overview
-   configuration
-   plugins
-   plugin-registry
-   faq
-   hacking
+   DevStack will make substantial changes to your system during
+   installation. Only run DevStack on servers or virtual machines that
+   are dedicated to this purpose.
 
 Quick Start
------------
+===========
 
-#. Select a Linux Distribution
-
-   Only Ubuntu 14.04 (Trusty), Fedora 22 (or Fedora 23) and CentOS/RHEL
-   7 are documented here. OpenStack also runs and is packaged on other
-   flavors of Linux such as OpenSUSE and Debian.
-
-#. Install Selected OS
-
-   In order to correctly install all the dependencies, we assume a
-   specific minimal version of the supported distributions to make it as
-   easy as possible. We recommend using a minimal install of Ubuntu or
-   Fedora server in a VM if this is your first time.
-
-#. Download DevStack
-
-   ::
-
-       git clone https://git.openstack.org/openstack-dev/devstack
-
-   The ``devstack`` repo contains a script that installs OpenStack and
-   templates for configuration files
-
-#. Configure
-
-   We recommend at least a :ref:`minimal-configuration` be set up.
-
-#. Add Stack User
-
-   Devstack should be run as a non-root user with sudo enabled
-   (standard logins to cloud images such as "ubuntu" or "cloud-user"
-   are usually fine).
-
-   You can quickly create a separate `stack` user to run DevStack with
-
-   ::
-
-       devstack/tools/create-stack-user.sh; su stack
-
-#. Start the install, this will take a few minutes.
-
-   ::
-
-       cd devstack; ./stack.sh
-
-Guides
-======
-
-Walk through various setups used by stackers
-
-.. toctree::
-   :glob:
-   :maxdepth: 1
-
-   guides/single-vm
-   guides/single-machine
-   guides/lxc
-   guides/multinode-lab
-   guides/neutron
-   guides/devstack-with-nested-kvm
-   guides/nova
-   guides/devstack-with-lbaas-v2
-
-All-In-One Single VM
---------------------
-
-Run :doc:`OpenStack in a VM <guides/single-vm>`. The VMs launched in your cloud will be slow as
-they are running in QEMU (emulation), but it is useful if you don't have
-spare hardware laying around. :doc:`[Read] <guides/single-vm>`
-
-All-In-One Single Machine
--------------------------
-
-Run :doc:`OpenStack on dedicated hardware <guides/single-machine>`  This can include a
-server-class machine or a laptop at home.
-:doc:`[Read] <guides/single-machine>`
-
-All-In-One LXC Container
--------------------------
-
-Run :doc:`OpenStack in a LXC container <guides/lxc>`. Beneficial for intermediate
-and advanced users. The VMs launched in this cloud will be fully accelerated but
-not all OpenStack features are supported. :doc:`[Read] <guides/lxc>`
-
-Multi-Node Lab
---------------
-
-Setup a :doc:`multi-node cluster <guides/multinode-lab>` with dedicated VLANs for VMs & Management.
-:doc:`[Read] <guides/multinode-lab>`
-
-DevStack with Neutron Networking
---------------------------------
-
-Building a DevStack cluster with :doc:`Neutron Networking <guides/neutron>`.
-This guide is meant for building lab environments with a dedicated
-control node and multiple compute nodes.
-
-DevStack with KVM-based Nested Virtualization
----------------------------------------------
-
-Procedure to setup :doc:`DevStack with KVM-based Nested Virtualization
-<guides/devstack-with-nested-kvm>`. With this setup, Nova instances
-will be more performant than with plain QEMU emulation.
-
-Nova and devstack
---------------------------------
-
-Guide to working with nova features :doc:`Nova and devstack <guides/nova>`.
-
-DevStack Documentation
-======================
-
-Overview
---------
-
-:doc:`An overview of DevStack goals and priorities <overview>`
-
-Configuration
+Install Linux
 -------------
 
-:doc:`Configuring and customizing the stack <configuration>`
+Start with a clean and minimal install of a Linux system. Devstack
+attempts to support Ubuntu 14.04/16.04, Fedora 23/24, CentOS/RHEL 7,
+as well as Debian and OpenSUSE.
 
-Plugins
+If you do not have a preference, Ubuntu 16.04 is the most tested, and
+will probably go the smoothest.
+
+Download DevStack
+-----------------
+
+::
+
+   git clone https://git.openstack.org/openstack-dev/devstack
+
+The ``devstack`` repo contains a script that installs OpenStack and
+templates for configuration files
+
+Create a local.conf
+-------------------
+
+Create a ``local.conf`` file with 4 passwords preset
+
+::
+
+   [[local|localrc]]
+   ADMIN_PASSWORD=secret
+   DATABASE_PASSWORD=$ADMIN_PASSWORD
+   RABBIT_PASSWORD=$ADMIN_PASSWORD
+   SERVICE_PASSWORD=$ADMIN_PASSWORD
+
+This is the minimum required config to get started with DevStack.
+
+Add Stack User
+--------------
+
+Devstack should be run as a non-root user with sudo enabled
+(standard logins to cloud images such as "ubuntu" or "cloud-user"
+are usually fine).
+
+You can quickly create a separate `stack` user to run DevStack with
+
+::
+
+   devstack/tools/create-stack-user.sh; su stack
+
+Start the install
+-----------------
+
+::
+
+   cd devstack; ./stack.sh
+
+This will take a 15 - 20 minutes, largely depending on the speed of
+your internet connection. Many git trees and packages will be
+installed during this process.
+
+Profit!
 -------
 
-:doc:`Extending DevStack with new features <plugins>`
+You now have a working DevStack! Congrats!
 
-FAQ
----
+Your devstack will have installed ``keystone``, ``glance``, ``nova``,
+``cinder``, ``neutron``, and ``horizon``. Floating IPs will be
+available, guests have access to the external world.
 
-:doc:`The DevStack FAQ <faq>`
+You can access horizon to experience the web interface to
+OpenStack, and manage vms, networks, volumes, and images from
+there.
 
-Contributing
-------------
+You can ``source openrc`` in your shell, and then use the
+``openstack`` command line tool to manage your devstack.
 
-:doc:`Pitching in to make DevStack a better place <hacking>`
+You can ``cd /opt/stack/tempest`` and run tempest tests that have
+been configured to work with your devstack.
 
+You can :doc:`make code changes to OpenStack and validate them
+<development>`.
+
+Going further
+-------------
+
+Learn more about our :doc:`configuration system <configuration>` to
+customize devstack for your needs. Including making adjustments to the
+default :doc:`networking <networking>`.
+
+Read :doc:`guides <guides>` for specific setups people have (note:
+guides are point in time contributions, and may not always be kept
+up to date to the latest devstack).
+
+Enable :doc:`devstack plugins <plugins>` to support additional
+services, features, and configuration not present in base devstack.
+
+Get :doc:`the big picture <overview>` of what we are trying to do
+with devstack, and help us by :doc:`contributing to the project
+<hacking>`.
diff --git a/doc/source/networking.rst b/doc/source/networking.rst
new file mode 100644
index 0000000..1d56c33
--- /dev/null
+++ b/doc/source/networking.rst
@@ -0,0 +1,97 @@
+=====================
+ DevStack Networking
+=====================
+
+An important part of the DevStack experience is networking that works
+by default for created guests. This might not be optimal for your
+particular testing environment, so this document tries it's best to
+explain what's going on.
+
+Defaults
+========
+
+If you don't specify any configuration you will get the following:
+
+* neutron (including l3 with openvswitch)
+* private project networks for each openstack project
+* a floating ip range of 172.24.4.0/24 with the gateway of 172.24.4.1
+* the demo project configured with fixed ips on 10.0.0.0/24
+* a ``br-ex`` interface controlled by neutron for all it's networking
+  (this is not connected to any physical interfaces).
+* DNS resolution for guests based on the resolv.conf for you host
+* an ip masq rule that allows created guests to route out
+
+This creates an environment which is isolated to the single
+host. Guests can get to the external network for package
+updates. Tempest tests will work in this environment.
+
+.. note::
+
+   By default all OpenStack environments have security group rules
+   which block all inbound packets to guests. If you want to be able
+   to ssh / ping your created guests you should run the following.
+
+   .. code-block:: bash
+
+      openstack security group rule create --proto icmp --dst-port 0 default
+      openstack security group rule create --proto tcp --dst-port 22 default
+
+Locally Accessible Guests
+=========================
+
+If you want to make you guests accessible other machines on your
+network, we have to connect ``br-ex`` to a physical interface.
+
+Dedicated Guest Interface
+-------------------------
+
+If you have 2 or more interfaces on your devstack server, you can
+allocate an interface to neutron to fully manage. This **should not**
+be the same interface you use to ssh into the devstack server itself.
+
+This is done by setting with the ``PUBLIC_INTERFACE`` attribute.
+
+.. code-block:: bash
+
+   [[local|localrc]]
+   PUBLIC_INTERFACE=eth1
+
+That will put all layer 2 traffic from your guests onto the main
+network. When running in this mode the ip masq rule is **not** added
+in your devstack, you are responsible for making routing work on your
+local network.
+
+Shared Guest Interface
+----------------------
+
+.. warning::
+
+   This is not a recommended configuration. Because of interactions
+   between ovs and bridging, if you reboot your box with active
+   networking you may loose network connectivity to your system.
+
+If you need your guests accessible on the network, but only have 1
+interface (using something like a NUC), you can share your one
+network. But in order for this to work you need to manually set a lot
+of addresses, and have them all exactly correct.
+
+.. code-block:: bash
+
+   [[local|localrc]]
+   PUBLIC_INTERFACE=eth0
+   HOST_IP=10.42.0.52
+   FLOATING_RANGE=10.42.0.52/24
+   PUBLIC_NETWORK_GATEWAY=10.42.0.1
+   Q_FLOATING_ALLOCATION_POOL=start=10.42.0.250,end=10.42.0.254
+
+In order for this scenario to work the floating ip network must match
+the default networking on your server. This breaks HOST_IP detection,
+as we exclude the floating range by default, so you have to specify
+that manually.
+
+The ``PUBLIC_NETWORK_GATEWAY`` is the gateway that server would normally
+use to get off the network. ``Q_FLOATING_ALLOCATION_POOL`` controls
+the range of floating ips that will be handed out. As we are sharing
+your existing network, you'll want to give it a slice that your local
+dhcp server is not allocating. Otherwise you could easily have
+conflicting ip addresses, and cause havoc with your local network.
diff --git a/doc/source/plugin-registry.rst b/doc/source/plugin-registry.rst
index bdb8d8b..bb85270 100644
--- a/doc/source/plugin-registry.rst
+++ b/doc/source/plugin-registry.rst
@@ -73,6 +73,7 @@
 magnum                                 `git://git.openstack.org/openstack/magnum <https://git.openstack.org/cgit/openstack/magnum>`__
 magnum-ui                              `git://git.openstack.org/openstack/magnum-ui <https://git.openstack.org/cgit/openstack/magnum-ui>`__
 manila                                 `git://git.openstack.org/openstack/manila <https://git.openstack.org/cgit/openstack/manila>`__
+masakari                               `git://git.openstack.org/openstack/masakari <https://git.openstack.org/cgit/openstack/masakari>`__
 mistral                                `git://git.openstack.org/openstack/mistral <https://git.openstack.org/cgit/openstack/mistral>`__
 monasca-analytics                      `git://git.openstack.org/openstack/monasca-analytics <https://git.openstack.org/cgit/openstack/monasca-analytics>`__
 monasca-api                            `git://git.openstack.org/openstack/monasca-api <https://git.openstack.org/cgit/openstack/monasca-api>`__
diff --git a/doc/source/site-map.rst b/doc/source/site-map.rst
new file mode 100644
index 0000000..801fc66
--- /dev/null
+++ b/doc/source/site-map.rst
@@ -0,0 +1,23 @@
+:orphan:
+
+.. the TOC on the front page actually makes the document a lot more
+   confusing. This lets us bury a toc which we can link in when
+   appropriate.
+
+==========
+ Site Map
+==========
+
+.. toctree::
+   :glob:
+   :maxdepth: 3
+
+   overview
+   configuration
+   networking
+   plugins
+   plugin-registry
+   faq
+   development
+   hacking
+   guides
diff --git a/lib/ceph b/lib/ceph
index 0c8d160..1e55c48 100644
--- a/lib/ceph
+++ b/lib/ceph
@@ -301,7 +301,6 @@
     iniset $NOVA_CONF libvirt rbd_user ${CINDER_CEPH_USER}
     iniset $NOVA_CONF libvirt rbd_secret_uuid ${CINDER_CEPH_UUID}
     iniset $NOVA_CONF libvirt inject_key false
-    iniset $NOVA_CONF libvirt inject_partition -2
     iniset $NOVA_CONF libvirt disk_cachemodes "network=writeback"
     iniset $NOVA_CONF libvirt images_type rbd
     iniset $NOVA_CONF libvirt images_rbd_pool ${NOVA_CEPH_POOL}
diff --git a/lib/cinder_backends/xiv b/lib/cinder_backends/xiv
deleted file mode 100644
index e8b5da0..0000000
--- a/lib/cinder_backends/xiv
+++ /dev/null
@@ -1,86 +0,0 @@
-#!/bin/bash
-#
-# Copyright 2014 IBM Corp.
-# Copyright (c) 2014 OpenStack Foundation
-# All Rights Reserved.
-#
-#    Licensed under the Apache License, Version 2.0 (the "License"); you may
-#    not use this file except in compliance with the License. You may obtain
-#    a copy of the License at
-#
-#         http://www.apache.org/licenses/LICENSE-2.0
-#
-#    Unless required by applicable law or agreed to in writing, software
-#    distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
-#    WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
-#    License for the specific language governing permissions and limitations
-#    under the License.
-#
-# Authors:
-#   Alon Marx <alonma@il.ibm.com>
-#
-
-# lib/cinder_plugins/xiv
-# Configure the xiv_ds8k driver for xiv testing
-
-# Enable xiv_ds8k driver for xiv with:
-#
-#   CINDER_ENABLED_BACKENDS+=,xiv:<volume-type-name>
-#   XIV_DRIVER_VERSION=<version-string>
-#   SAN_IP=<storage-ip-or-hostname>
-#   SAN_LOGIN=<storage-admin-account>
-#   SAN_PASSWORD=<storage-admin-password>
-#   SAN_CLUSTERNAME=<cluster-name>
-#   CONNECTION_TYPE=<connection-type> iscsi|fc
-#   XIV_CHAP=<chap-type> disabled|enabled
-
-# Dependencies:
-#
-# - ``functions`` file
-# - ``cinder`` configurations
-
-# configure_cinder_backend_xiv - Configure Cinder for xiv backends
-
-# Save trace setting
-_XTRACE_CINDER_XIV=$(set +o | grep xtrace)
-set +o xtrace
-
-# Defaults
-# --------
-# Set up default directories
-
-
-# Entry Points
-# ------------
-
-# configure_cinder_backend_xiv - Set config files, create data dirs, etc
-function configure_cinder_backend_xiv {
-
-    local be_name=$1
-
-    python -c 'from xiv_ds8k_openstack.xiv_nova_proxy import XIVNovaProxy'
-    if [ $? -ne 0 ]; then
-        die $LINENO "XIV_DS8K driver is missing. Please install first"
-    fi
-
-    # For reference:
-    # ``XIV_DS8K_BACKEND='IBM-XIV_'${SAN_IP}'_'${SAN_CLUSTERNAME}'_'${CONNECTION_TYPE}``
-    iniset $CINDER_CONF DEFAULT xiv_ds8k_driver_version $XIV_DRIVER_VERSION
-
-    iniset $CINDER_CONF $be_name san_ip $SAN_IP
-    iniset $CINDER_CONF $be_name san_login $SAN_LOGIN
-    iniset $CINDER_CONF $be_name san_password $SAN_PASSWORD
-    iniset $CINDER_CONF $be_name san_clustername $SAN_CLUSTERNAME
-    iniset $CINDER_CONF $be_name xiv_ds8k_connection_type $CONNECTION_TYPE
-    iniset $CINDER_CONF $be_name volume_backend_name $be_name
-    iniset $CINDER_CONF $be_name volume_driver 'cinder.volume.drivers.ibm.xiv_ds8k.XIVDS8KDriver'
-    iniset $CINDER_CONF $be_name xiv_ds8k_proxy 'xiv_ds8k_openstack.xiv_nova_proxy.XIVNovaProxy'
-    iniset $CINDER_CONF $be_name xiv_chap $XIV_CHAP
-}
-
-# Restore xtrace
-$_XTRACE_CINDER_XIV
-
-# Local variables:
-# mode: shell-script
-# End:
diff --git a/lib/horizon b/lib/horizon
index 0517e32..78cbe8b 100644
--- a/lib/horizon
+++ b/lib/horizon
@@ -69,9 +69,8 @@
 # cleanup_horizon() - Remove residual data files, anything left over from previous
 # runs that a clean run would need to clean up
 function cleanup_horizon {
-    local horizon_conf
-    horizon_conf=$(apache_site_config_for horizon)
-    sudo rm -f $horizon_conf
+    disable_apache_site horizon
+    sudo rm -f $(apache_site_config_for horizon)
 }
 
 # configure_horizon() - Set config files, create data dirs, etc
diff --git a/lib/neutron b/lib/neutron
index 5cab8e1..c1552e3 100644
--- a/lib/neutron
+++ b/lib/neutron
@@ -166,6 +166,7 @@
         iniset $NEUTRON_PLUGIN_CONF ml2 type_drivers vxlan
         iniset $NEUTRON_PLUGIN_CONF ml2 mechanism_drivers openvswitch,linuxbridge
         iniset $NEUTRON_PLUGIN_CONF ml2_type_vxlan vni_ranges 1001:2000
+        iniset $NEUTRON_PLUGIN_CONF ml2 extension_drivers port_security
     fi
 
     # Neutron OVS or LB agent
@@ -188,6 +189,9 @@
         cp $NEUTRON_DIR/etc/dhcp_agent.ini.sample $NEUTRON_DHCP_CONF
 
         iniset $NEUTRON_DHCP_CONF DEFAULT debug True
+        # make it so we have working DNS from guests
+        iniset $NEUTRON_DHCP_CONF DEFAULT dnsmasq_local_resolv True
+
         iniset $NEUTRON_DHCP_CONF agent root_helper_daemon "$NEUTRON_ROOTWRAP_DAEMON_CMD"
         iniset $NEUTRON_DHCP_CONF DEFAULT interface_driver $NEUTRON_AGENT
         neutron_plugin_configure_dhcp_agent $NEUTRON_DHCP_CONF
@@ -425,16 +429,16 @@
     fi
     if is_service_enabled neutron-l3; then
         run_process neutron-l3 "$NEUTRON_BIN_DIR/$NEUTRON_L3_BINARY $NEUTRON_CONFIG_ARG"
-        # XXX(sc68cal) - Here's where plugins can wire up their own networks instead
-        # of the code in lib/neutron_plugins/services/l3
-        if type -p neutron_plugin_create_initial_networks > /dev/null; then
-            neutron_plugin_create_initial_networks
-        else
-            # XXX(sc68cal) Load up the built in Neutron networking code and build a topology
-            source $TOP_DIR/lib/neutron_plugins/services/l3
-            # Create the networks using servic
-            create_neutron_initial_network
-        fi
+    fi
+    # XXX(sc68cal) - Here's where plugins can wire up their own networks instead
+    # of the code in lib/neutron_plugins/services/l3
+    if type -p neutron_plugin_create_initial_networks > /dev/null; then
+        neutron_plugin_create_initial_networks
+    else
+        # XXX(sc68cal) Load up the built in Neutron networking code and build a topology
+        source $TOP_DIR/lib/neutron_plugins/services/l3
+        # Create the networks using servic
+        create_neutron_initial_network
     fi
     if is_service_enabled neutron-metadata-agent; then
         run_process neutron-metadata-agent "$NEUTRON_BIN_DIR/$NEUTRON_META_BINARY $NEUTRON_CONFIG_ARG"
diff --git a/lib/neutron-legacy b/lib/neutron-legacy
index 5d91cda..25fb6b7 100644
--- a/lib/neutron-legacy
+++ b/lib/neutron-legacy
@@ -292,9 +292,6 @@
 
 function _determine_config_l3 {
     local opts="--config-file $NEUTRON_CONF --config-file $Q_L3_CONF_FILE"
-    if is_service_enabled q-fwaas; then
-        opts+=" --config-file $Q_FWAAS_CONF_FILE"
-    fi
     echo "$opts"
 }
 
@@ -782,6 +779,8 @@
     cp $NEUTRON_DIR/etc/dhcp_agent.ini.sample $Q_DHCP_CONF_FILE
 
     iniset $Q_DHCP_CONF_FILE DEFAULT debug $ENABLE_DEBUG_LOG_LEVEL
+    # make it so we have working DNS from guests
+    iniset $Q_DHCP_CONF_FILE DEFAULT dnsmasq_local_resolv True
     iniset $Q_DHCP_CONF_FILE AGENT root_helper "$Q_RR_COMMAND"
     if [[ "$Q_USE_ROOTWRAP_DAEMON" == "True" ]]; then
         iniset $Q_DHCP_CONF_FILE AGENT root_helper_daemon "$Q_RR_DAEMON_COMMAND"
@@ -1003,55 +1002,6 @@
     test_with_retry "$testcmd" "server $ip didn't become ssh-able" $timeout_sec
 }
 
-# Neutron 3rd party programs
-#---------------------------
-
-# please refer to ``lib/neutron_thirdparty/README.md`` for details
-NEUTRON_THIRD_PARTIES=""
-for f in $TOP_DIR/lib/neutron_thirdparty/*; do
-    third_party=$(basename $f)
-    if is_service_enabled $third_party; then
-        source $TOP_DIR/lib/neutron_thirdparty/$third_party
-        NEUTRON_THIRD_PARTIES="$NEUTRON_THIRD_PARTIES,$third_party"
-    fi
-done
-
-function _neutron_third_party_do {
-    for third_party in ${NEUTRON_THIRD_PARTIES//,/ }; do
-        ${1}_${third_party}
-    done
-}
-
-# configure_neutron_third_party() - Set config files, create data dirs, etc
-function configure_neutron_third_party {
-    _neutron_third_party_do configure
-}
-
-# init_neutron_third_party() - Initialize databases, etc.
-function init_neutron_third_party {
-    _neutron_third_party_do init
-}
-
-# install_neutron_third_party() - Collect source and prepare
-function install_neutron_third_party {
-    _neutron_third_party_do install
-}
-
-# start_neutron_third_party() - Start running processes, including screen
-function start_neutron_third_party {
-    _neutron_third_party_do start
-}
-
-# stop_neutron_third_party - Stop running processes (non-screen)
-function stop_neutron_third_party {
-    _neutron_third_party_do stop
-}
-
-# check_neutron_third_party_integration() - Check that third party integration is sane
-function check_neutron_third_party_integration {
-    _neutron_third_party_do check
-}
-
 # Restore xtrace
 $_XTRACE_NEUTRON
 
diff --git a/lib/neutron_plugins/linuxbridge_agent b/lib/neutron_plugins/linuxbridge_agent
index e5a7b76..a6a163c 100644
--- a/lib/neutron_plugins/linuxbridge_agent
+++ b/lib/neutron_plugins/linuxbridge_agent
@@ -44,7 +44,7 @@
 
 function neutron_plugin_configure_dhcp_agent {
     local conf_file=$1
-    iniset $conf_file DEFAULT dhcp_agent_manager neutron.agent.dhcp_agent.DhcpAgentWithStateReport
+    :
 }
 
 function neutron_plugin_configure_l3_agent {
@@ -52,7 +52,6 @@
     sudo brctl addbr $PUBLIC_BRIDGE
     set_mtu $PUBLIC_BRIDGE $PUBLIC_BRIDGE_MTU
     iniset $conf_file DEFAULT external_network_bridge
-    iniset $conf_file DEFAULT l3_agent_manager neutron.agent.l3_agent.L3NATAgentWithStateReport
 }
 
 function neutron_plugin_configure_plugin_agent {
diff --git a/lib/neutron_plugins/openvswitch_agent b/lib/neutron_plugins/openvswitch_agent
index b4a53e4..e27b8a6 100644
--- a/lib/neutron_plugins/openvswitch_agent
+++ b/lib/neutron_plugins/openvswitch_agent
@@ -29,13 +29,12 @@
 
 function neutron_plugin_configure_dhcp_agent {
     local conf_file=$1
-    iniset $conf_file DEFAULT dhcp_agent_manager neutron.agent.dhcp_agent.DhcpAgentWithStateReport
+    :
 }
 
 function neutron_plugin_configure_l3_agent {
     local conf_file=$1
     _neutron_ovs_base_configure_l3_agent
-    iniset $conf_file DEFAULT l3_agent_manager neutron.agent.l3_agent.L3NATAgentWithStateReport
 }
 
 function neutron_plugin_configure_plugin_agent {
diff --git a/lib/neutron_plugins/ovs_base b/lib/neutron_plugins/ovs_base
index 9e1421f..f6d10ea 100644
--- a/lib/neutron_plugins/ovs_base
+++ b/lib/neutron_plugins/ovs_base
@@ -19,7 +19,7 @@
 
 function _neutron_ovs_base_add_bridge {
     local bridge=$1
-    local addbr_cmd="sudo ovs-vsctl --no-wait -- --may-exist add-br $bridge"
+    local addbr_cmd="sudo ovs-vsctl -- --may-exist add-br $bridge"
 
     if [ "$OVS_DATAPATH_TYPE" != "system" ] ; then
         addbr_cmd="$addbr_cmd -- set Bridge $bridge datapath_type=${OVS_DATAPATH_TYPE}"
diff --git a/lib/neutron_plugins/services/l3 b/lib/neutron_plugins/services/l3
index 2180099..61b8402 100644
--- a/lib/neutron_plugins/services/l3
+++ b/lib/neutron_plugins/services/l3
@@ -102,10 +102,20 @@
 
     neutron_plugin_configure_l3_agent $Q_L3_CONF_FILE
 
-    _move_neutron_addresses_route "$PUBLIC_INTERFACE" "$OVS_PHYSICAL_BRIDGE" True False "inet"
+    # If we've given a PUBLIC_INTERFACE to take over, then we assume
+    # that we can own the whole thing, and privot it into the OVS
+    # bridge. If we are not, we're probably on a single interface
+    # machine, and we just setup NAT so that fixed guests can get out.
+    if [[ -n "$PUBLIC_INTERFACE" ]]; then
+        _move_neutron_addresses_route "$PUBLIC_INTERFACE" "$OVS_PHYSICAL_BRIDGE" True False "inet"
 
-    if [[ $(ip -f inet6 a s dev "$PUBLIC_INTERFACE" | grep -c 'global') != 0 ]]; then
-        _move_neutron_addresses_route "$PUBLIC_INTERFACE" "$OVS_PHYSICAL_BRIDGE" False False "inet6"
+        if [[ $(ip -f inet6 a s dev "$PUBLIC_INTERFACE" | grep -c 'global') != 0 ]]; then
+            _move_neutron_addresses_route "$PUBLIC_INTERFACE" "$OVS_PHYSICAL_BRIDGE" False False "inet6"
+        fi
+    else
+        local default_dev=""
+        default_dev=$(ip route | grep ^default | awk '{print $5}')
+        sudo iptables -t nat -A POSTROUTING -o $default_dev -s $FLOATING_RANGE -j MASQUERADE
     fi
 }
 
diff --git a/lib/neutron_thirdparty/README.md b/lib/neutron_thirdparty/README.md
deleted file mode 100644
index 905ae77..0000000
--- a/lib/neutron_thirdparty/README.md
+++ /dev/null
@@ -1,41 +0,0 @@
-Neutron third party specific files
-==================================
-Some Neutron plugins require third party programs to function.
-The files under the directory, ``lib/neutron_thirdparty/``, will be used
-when their service are enabled.
-Third party program specific configuration variables should be in this file.
-
-* filename: ``<third_party>``
-  * The corresponding file name should be same to service name, ``<third_party>``.
-
-functions
----------
-``lib/neutron-legacy`` calls the following functions when the ``<third_party>`` is enabled
-
-functions to be implemented
-* ``configure_<third_party>``:
-  set config files, create data dirs, etc
-  e.g.
-  sudo python setup.py deploy
-  iniset $XXXX_CONF...
-
-* ``init_<third_party>``:
-  initialize databases, etc
-
-* ``install_<third_party>``:
-  collect source and prepare
-  e.g.
-  git clone xxx
-
-* ``start_<third_party>``:
-  start running processes, including screen if USE_SCREEN=True
-  e.g.
-  run_process XXXX "$XXXX_DIR/bin/XXXX-bin"
-
-* ``stop_<third_party>``:
-  stop running processes (non-screen)
-  e.g.
-  stop_process XXXX
-
-* ``check_<third_party>``:
-  verify that the integration between neutron server and third-party components is sane
diff --git a/lib/neutron_thirdparty/bigswitch_floodlight b/lib/neutron_thirdparty/bigswitch_floodlight
deleted file mode 100644
index 45a4f2e..0000000
--- a/lib/neutron_thirdparty/bigswitch_floodlight
+++ /dev/null
@@ -1,54 +0,0 @@
-#!/bin/bash
-#
-# Big Switch/FloodLight  OpenFlow Controller
-# ------------------------------------------
-
-# Save trace setting
-_XTRACE_NEUTRON_BIGSWITCH=$(set +o | grep xtrace)
-set +o xtrace
-
-BS_FL_CONTROLLERS_PORT=${BS_FL_CONTROLLERS_PORT:-localhost:80}
-BS_FL_OF_PORT=${BS_FL_OF_PORT:-6633}
-
-function configure_bigswitch_floodlight {
-    :
-}
-
-function init_bigswitch_floodlight {
-    install_neutron_agent_packages
-
-    echo -n "Installing OVS managed by the openflow controllers:"
-    echo ${BS_FL_CONTROLLERS_PORT}
-
-    # Create local OVS bridge and configure it
-    sudo ovs-vsctl --no-wait -- --if-exists del-br ${OVS_BRIDGE}
-    sudo ovs-vsctl --no-wait add-br ${OVS_BRIDGE}
-    sudo ovs-vsctl --no-wait br-set-external-id ${OVS_BRIDGE} bridge-id ${OVS_BRIDGE}
-
-    ctrls=
-    for ctrl in `echo ${BS_FL_CONTROLLERS_PORT} | tr ',' ' '`; do
-        ctrl=${ctrl%:*}
-        ctrls="${ctrls} tcp:${ctrl}:${BS_FL_OF_PORT}"
-    done
-    echo "Adding Network conttrollers: " ${ctrls}
-    sudo ovs-vsctl --no-wait set-controller ${OVS_BRIDGE} ${ctrls}
-}
-
-function install_bigswitch_floodlight {
-    :
-}
-
-function start_bigswitch_floodlight {
-    :
-}
-
-function stop_bigswitch_floodlight {
-    :
-}
-
-function check_bigswitch_floodlight {
-    :
-}
-
-# Restore xtrace
-$_XTRACE_NEUTRON_BIGSWITCH
diff --git a/lib/neutron_thirdparty/vmware_nsx b/lib/neutron_thirdparty/vmware_nsx
deleted file mode 100644
index e182fca..0000000
--- a/lib/neutron_thirdparty/vmware_nsx
+++ /dev/null
@@ -1,4 +0,0 @@
-#!/bin/bash
-
-# REVISIT(roeyc): this file left empty so that 'enable_service vmware_nsx'
-# continues to work.
diff --git a/lib/nova b/lib/nova
index 16f6e9b..1369c40 100644
--- a/lib/nova
+++ b/lib/nova
@@ -128,7 +128,7 @@
 # --------------------------
 
 NETWORK_MANAGER=${NETWORK_MANAGER:-${NET_MAN:-FlatDHCPManager}}
-PUBLIC_INTERFACE=${PUBLIC_INTERFACE:-$PUBLIC_INTERFACE_DEFAULT}
+
 VLAN_INTERFACE=${VLAN_INTERFACE:-$GUEST_INTERFACE_DEFAULT}
 FLAT_NETWORK_BRIDGE=${FLAT_NETWORK_BRIDGE:-$FLAT_NETWORK_BRIDGE_DEFAULT}
 
@@ -659,8 +659,9 @@
 }
 
 function create_nova_conf_nova_network {
+    local public_interface=${PUBLIC_INTERFACE:-$PUBLIC_INTERFACE_DEFAULT}
     iniset $NOVA_CONF DEFAULT network_manager "nova.network.manager.$NETWORK_MANAGER"
-    iniset $NOVA_CONF DEFAULT public_interface "$PUBLIC_INTERFACE"
+    iniset $NOVA_CONF DEFAULT public_interface "$public_interface"
     iniset $NOVA_CONF DEFAULT vlan_interface "$VLAN_INTERFACE"
     iniset $NOVA_CONF DEFAULT flat_network_bridge "$FLAT_NETWORK_BRIDGE"
     if [ -n "$FLAT_INTERFACE" ]; then
diff --git a/lib/nova_plugins/hypervisor-fake b/lib/nova_plugins/hypervisor-fake
index 2434dce..6ac2199 100644
--- a/lib/nova_plugins/hypervisor-fake
+++ b/lib/nova_plugins/hypervisor-fake
@@ -36,7 +36,7 @@
 
 # configure_nova_hypervisor - Set config files, create data dirs, etc
 function configure_nova_hypervisor {
-    iniset $NOVA_CONF DEFAULT compute_driver "nova.virt.fake.FakeDriver"
+    iniset $NOVA_CONF DEFAULT compute_driver "fake.FakeDriver"
     # Disable arbitrary limits
     iniset $NOVA_CONF DEFAULT quota_instances -1
     iniset $NOVA_CONF DEFAULT quota_cores -1
diff --git a/lib/nova_plugins/hypervisor-libvirt b/lib/nova_plugins/hypervisor-libvirt
index 51d807a..20dde8e 100644
--- a/lib/nova_plugins/hypervisor-libvirt
+++ b/lib/nova_plugins/hypervisor-libvirt
@@ -58,9 +58,13 @@
         iniset $NOVA_CONF libvirt cpu_mode "host-passthrough"
     fi
 
-    # File injection is being disabled by default in the near future -
-    # disable it here for now to avoid surprises later.
-    iniset $NOVA_CONF libvirt inject_partition '-2'
+    if isset ENABLE_FILE_INJECTION; then
+        if [ "$ENABLE_FILE_INJECTION" == "True" ]; then
+            # -1 means use libguestfs to inspect the guest OS image for the
+            # root partition to use for file injection.
+            iniset $NOVA_CONF libvirt inject_partition '-1'
+        fi
+    fi
 
     if [[ "$LIBVIRT_TYPE" = "parallels" ]]; then
         iniset $NOVA_CONF libvirt connection_uri "parallels+unix:///system"
diff --git a/lib/nova_plugins/hypervisor-xenserver b/lib/nova_plugins/hypervisor-xenserver
index e7f1e87..e75226a 100644
--- a/lib/nova_plugins/hypervisor-xenserver
+++ b/lib/nova_plugins/hypervisor-xenserver
@@ -24,8 +24,6 @@
 # Defaults
 # --------
 
-PUBLIC_INTERFACE_DEFAULT=eth2
-GUEST_INTERFACE_DEFAULT=eth1
 # Allow ``build_domU.sh`` to specify the flat network bridge via kernel args
 FLAT_NETWORK_BRIDGE_DEFAULT=$(sed -e 's/.* flat_network_bridge=\([[:alnum:]]*\).*$/\1/g' /proc/cmdline)
 if is_service_enabled neutron; then
diff --git a/lib/oslo b/lib/oslo
index 1773da2..e34e48a 100644
--- a/lib/oslo
+++ b/lib/oslo
@@ -26,6 +26,8 @@
 GITDIR["cliff"]=$DEST/cliff
 GITDIR["debtcollector"]=$DEST/debtcollector
 GITDIR["futurist"]=$DEST/futurist
+GITDIR["os-client-config"]=$DEST/os-client-config
+GITDIR["osc-lib"]=$DEST/osc-lib
 GITDIR["oslo.cache"]=$DEST/oslo.cache
 GITDIR["oslo.concurrency"]=$DEST/oslo.concurrency
 GITDIR["oslo.config"]=$DEST/oslo.config
@@ -71,6 +73,8 @@
     _do_install_oslo_lib "cliff"
     _do_install_oslo_lib "debtcollector"
     _do_install_oslo_lib "futurist"
+    _do_install_oslo_lib "osc-lib"
+    _do_install_oslo_lib "os-client-config"
     _do_install_oslo_lib "oslo.cache"
     _do_install_oslo_lib "oslo.concurrency"
     _do_install_oslo_lib "oslo.config"
diff --git a/lib/tempest b/lib/tempest
index e4f80b8..67fb454 100644
--- a/lib/tempest
+++ b/lib/tempest
@@ -236,6 +236,8 @@
         fi
     fi
 
+    iniset $TEMPEST_CONFIG network project_network_cidr $FIXED_RANGE
+
     ssh_connect_method=${TEMPEST_SSH_CONNECT_METHOD:-$ssh_connect_method}
 
     # the public network (for floating ip access) is only available
@@ -352,6 +354,7 @@
         iniset $TEMPEST_CONFIG compute max_microversion $tempest_compute_max_microversion
     fi
 
+    iniset $TEMPEST_CONFIG compute-feature-enabled personality ${ENABLE_FILE_INJECTION:-False}
     iniset $TEMPEST_CONFIG compute-feature-enabled resize True
     iniset $TEMPEST_CONFIG compute-feature-enabled live_migration ${LIVE_MIGRATION_AVAILABLE:-False}
     iniset $TEMPEST_CONFIG compute-feature-enabled change_password False
@@ -451,15 +454,26 @@
     fi
 
     # Using ``CINDER_ENABLED_BACKENDS``
+    # Cinder uses a comma separated list with "type:backend_name":
+    #  CINDER_ENABLED_BACKENDS = ceph:cephBE1,lvm:lvmBE2,foo:my_foo
     if [[ -n "$CINDER_ENABLED_BACKENDS" ]] && [[ $CINDER_ENABLED_BACKENDS =~ .*,.* ]]; then
+        # We have at least 2 backends
         iniset $TEMPEST_CONFIG volume-feature-enabled multi_backend "True"
-        local i=1
+        local add_comma_seperator=0
+        local backends_list=''
         local be
+        # Tempest uses a comma separated list of backend_names:
+        #   backend_names = BACKEND_1,BACKEND_2
         for be in ${CINDER_ENABLED_BACKENDS//,/ }; do
-            local be_name=${be##*:}
-            iniset $TEMPEST_CONFIG volume "backend${i}_name" "$be_name"
-            i=$(( i + 1 ))
+            if [ "$add_comma_seperator" -eq "1" ]; then
+                backends_list+=,${be##*:}
+            else
+            # first element in the list
+                backends_list+=${be##*:}
+                add_comma_seperator=1
+            fi
         done
+        iniset $TEMPEST_CONFIG volume "backend_names" "$backends_list"
     fi
 
     if [ $TEMPEST_VOLUME_DRIVER != "default" -o \
@@ -482,6 +496,7 @@
         iniset $TEMPEST_CONFIG baremetal driver_enabled True
         iniset $TEMPEST_CONFIG baremetal unprovision_timeout $BUILD_TIMEOUT
         iniset $TEMPEST_CONFIG baremetal active_timeout $BUILD_TIMEOUT
+        iniset $TEMPEST_CONFIG baremetal deploywait_timeout $BUILD_TIMEOUT
         iniset $TEMPEST_CONFIG baremetal deploy_img_dir $FILES
         iniset $TEMPEST_CONFIG baremetal node_uuid $IRONIC_NODE_UUID
         iniset $TEMPEST_CONFIG compute-feature-enabled change_password False
@@ -559,16 +574,14 @@
     # Run ``verify_tempest_config -ur`` to retrieve enabled extensions on API endpoints
     # NOTE(mtreinish): This must be done after auth settings are added to the tempest config
     tox -evenv -- tempest verify-config -uro $tmp_cfg_file
-    # Nova API extensions
-    local compute_api_extensions=${COMPUTE_API_EXTENSIONS:-"all"}
-    if [[ ! -z "$DISABLE_COMPUTE_API_EXTENSIONS" ]]; then
-        # Enabled extensions are either the ones explicitly specified or those available on the API endpoint
-        compute_api_extensions=${COMPUTE_API_EXTENSIONS:-$(iniget $tmp_cfg_file compute-feature-enabled api_extensions | tr -d " ")}
-        # Remove disabled extensions
-        compute_api_extensions=$(remove_disabled_extensions $compute_api_extensions $DISABLE_COMPUTE_API_EXTENSIONS)
-    fi
-    iniset $TEMPEST_CONFIG compute-feature-enabled api_extensions $compute_api_extensions
+
     # Neutron API Extensions
+
+    # disable metering if we didn't enable the service
+    if ! is_service_enabled q-metering; then
+        DISABLE_NETWORK_API_EXTENSIONS+=", metering"
+    fi
+
     local network_api_extensions=${NETWORK_API_EXTENSIONS:-"all"}
     if [[ ! -z "$DISABLE_NETWORK_API_EXTENSIONS" ]]; then
         # Enabled extensions are either the ones explicitly specified or those available on the API endpoint
diff --git a/samples/local.conf b/samples/local.conf
index 06ac185..6d5351f 100644
--- a/samples/local.conf
+++ b/samples/local.conf
@@ -10,7 +10,7 @@
 
 # This is a collection of some of the settings we have found to be useful
 # in our DevStack development environments. Additional settings are described
-# in http://devstack.org/local.conf.html
+# in http://docs.openstack.org/developer/devstack/configuration.html#local-conf
 # These should be considered as samples and are unsupported DevStack code.
 
 # The ``localrc`` section replaces the old ``localrc`` configuration file.
diff --git a/stack.sh b/stack.sh
index 4cace9d..823b63b 100755
--- a/stack.sh
+++ b/stack.sh
@@ -843,7 +843,6 @@
 if is_service_enabled neutron; then
     # Network service
     stack_install_service neutron
-    install_neutron_third_party
 fi
 
 if is_service_enabled nova; then
@@ -1093,15 +1092,6 @@
     fi
 fi
 
-# Some Neutron plugins require network controllers which are not
-# a part of the OpenStack project. Configure and start them.
-if is_service_enabled neutron; then
-    configure_neutron_third_party
-    init_neutron_third_party
-    start_neutron_third_party
-fi
-
-
 # Nova
 # ----
 
@@ -1235,11 +1225,9 @@
 if is_service_enabled neutron-api; then
     echo_summary "Starting Neutron"
     start_neutron_api
-    # check_neutron_third_party_integration
 elif is_service_enabled q-svc; then
     echo_summary "Starting Neutron"
     start_neutron_service_and_check
-    check_neutron_third_party_integration
 elif is_service_enabled $DATABASE_BACKENDS && is_service_enabled n-net; then
     NM_CONF=${NOVA_CONF}
     if is_service_enabled n-cell; then
diff --git a/stackrc b/stackrc
index acb7d3f..bfb897b 100644
--- a/stackrc
+++ b/stackrc
@@ -70,11 +70,13 @@
     # Keystone - nothing works without keystone
     ENABLED_SERVICES=key
     # Nova - services to support libvirt based openstack clouds
-    ENABLED_SERVICES+=,n-api,n-cpu,n-net,n-cond,n-sch,n-novnc,n-cauth
+    ENABLED_SERVICES+=,n-api,n-cpu,n-cond,n-sch,n-novnc,n-cauth
     # Glance services needed for Nova
     ENABLED_SERVICES+=,g-api,g-reg
     # Cinder
     ENABLED_SERVICES+=,c-sch,c-api,c-vol
+    # Neutron
+    ENABLED_SERVICES+=,q-svc,q-dhcp,q-meta,q-agt,q-l3
     # Dashboard
     ENABLED_SERVICES+=,horizon
     # Additional services
@@ -506,10 +508,19 @@
 GITREPO["os-brick"]=${OS_BRICK_REPO:-${GIT_BASE}/openstack/os-brick.git}
 GITBRANCH["os-brick"]=${OS_BRICK_BRANCH:-master}
 
+# os-client-config to manage clouds.yaml and friends
+GITREPO["os-client-config"]=${OS_CLIENT_CONFIG_REPO:-${GIT_BASE}/openstack/os-client-config.git}
+GITBRANCH["os-client-config"]=${OS_CLIENT_CONFIG_BRANCH:-master}
+GITDIR["os-client-config"]=$DEST/os-client-config
+
 # os-vif library to communicate between Neutron to Nova
 GITREPO["os-vif"]=${OS_VIF_REPO:-${GIT_BASE}/openstack/os-vif.git}
 GITBRANCH["os-vif"]=${OS_VIF_BRANCH:-master}
 
+# osc-lib OpenStackClient common lib
+GITREPO["osc-lib"]=${OSC_LIB_REPO:-${GIT_BASE}/openstack/osc-lib.git}
+GITBRANCH["osc-lib"]=${OSC_LIB_BRANCH:-master}
+
 # ironic common lib
 GITREPO["ironic-lib"]=${IRONIC_LIB_REPO:-${GIT_BASE}/openstack/ironic-lib.git}
 GITBRANCH["ironic-lib"]=${IRONIC_LIB_BRANCH:-master}
@@ -710,6 +721,8 @@
 PRIVATE_NETWORK_NAME=${PRIVATE_NETWORK_NAME:-"private"}
 PUBLIC_NETWORK_NAME=${PUBLIC_NETWORK_NAME:-"public"}
 
+PUBLIC_INTERFACE=${PUBLIC_INTERFACE:-""}
+
 # Set default screen name
 SCREEN_NAME=${SCREEN_NAME:-stack}
 
diff --git a/tests/test_libs_from_pypi.sh b/tests/test_libs_from_pypi.sh
index bb58088..fb55023 100755
--- a/tests/test_libs_from_pypi.sh
+++ b/tests/test_libs_from_pypi.sh
@@ -36,8 +36,8 @@
 ALL_LIBS+=" python-cinderclient glance_store oslo.concurrency oslo.db"
 ALL_LIBS+=" oslo.versionedobjects oslo.vmware keystonemiddleware"
 ALL_LIBS+=" oslo.serialization django_openstack_auth"
-ALL_LIBS+=" python-openstackclient oslo.rootwrap oslo.i18n"
-ALL_LIBS+=" oslo.utils python-swiftclient"
+ALL_LIBS+=" python-openstackclient osc-lib os-client-config oslo.rootwrap"
+ALL_LIBS+=" oslo.i18n oslo.utils python-swiftclient"
 ALL_LIBS+=" python-neutronclient tooz ceilometermiddleware oslo.policy"
 ALL_LIBS+=" debtcollector os-brick automaton futurist oslo.service"
 ALL_LIBS+=" oslo.cache oslo.reports osprofiler"
diff --git a/tools/fixup_stuff.sh b/tools/fixup_stuff.sh
index 193a1f7..4dec95e 100755
--- a/tools/fixup_stuff.sh
+++ b/tools/fixup_stuff.sh
@@ -162,7 +162,11 @@
 fi
 
 # The version of pip(1.5.4) supported by python-virtualenv(1.11.4) has
-# connection issues under proxy, hence uninstalling python-virtualenv package
-# and installing the latest version using pip.
-uninstall_package python-virtualenv
-pip_install -U virtualenv
+# connection issues under proxy so re-install the latest version using
+# pip. To avoid having pip's virtualenv overwritten by the distro's
+# package (e.g. due to installing a distro package with a dependency
+# on python-virtualenv), first install the distro python-virtualenv
+# to satisfy any dependencies then use pip to overwrite it.
+
+install_package python-virtualenv
+pip_install -U --force-reinstall virtualenv
diff --git a/unstack.sh b/unstack.sh
index a69b218..ece69ac 100755
--- a/unstack.sh
+++ b/unstack.sh
@@ -168,7 +168,6 @@
 
 if is_service_enabled neutron; then
     stop_neutron
-    stop_neutron_third_party
     cleanup_neutron
 fi