Merge "fix nova's fake virt driver plugin"
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..d89637e 100644
--- a/doc/source/index.rst
+++ b/doc/source/index.rst
@@ -1,163 +1,134 @@
-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.
+
+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/site-map.rst b/doc/source/site-map.rst
new file mode 100644
index 0000000..74b944b
--- /dev/null
+++ b/doc/source/site-map.rst
@@ -0,0 +1,22 @@
+: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
+ 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 b/lib/cinder
index 69ff4c4..a87f395 100644
--- a/lib/cinder
+++ b/lib/cinder
@@ -273,8 +273,6 @@
iniset $CINDER_CONF DEFAULT os_region_name "$REGION_NAME"
- iniset $CINDER_CONF privsep_osbrick helper_command "sudo cinder-rootwrap \$rootwrap_config privsep-helper --config-file $CINDER_CONF"
-
if is_service_enabled c-vol && [[ -n "$CINDER_ENABLED_BACKENDS" ]]; then
local enabled_backends=""
local default_name=""
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/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 67a80b9..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}
@@ -481,11 +481,6 @@
iniset $NOVA_CONF DEFAULT bindir "/usr/bin"
fi
- iniset $NOVA_CONF privsep_osbrick helper_command "sudo nova-rootwrap \$rootwrap_config privsep-helper --config-file $NOVA_CONF"
-
- iniset $NOVA_CONF vif_plug_ovs_privileged helper_command "sudo nova-rootwrap \$rootwrap_config privsep-helper --config-file $NOVA_CONF"
- iniset $NOVA_CONF vif_plug_linux_bridge_privileged helper_command "sudo nova-rootwrap \$rootwrap_config privsep-helper --config-file $NOVA_CONF"
-
if is_service_enabled n-api; then
if is_service_enabled n-api-meta; then
# If running n-api-meta as a separate service
@@ -664,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-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/tempest b/lib/tempest
index e4f80b8..6168fbf 100644
--- a/lib/tempest
+++ b/lib/tempest
@@ -352,6 +352,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
@@ -482,6 +483,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 +561,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..4fefe8d 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
@@ -710,6 +712,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/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
