Merge "Write clouds.yaml to only /etc" into stable/liberty

It's not used, and a recent change to trim down projects lists in
devstack-gate broke devstack in the gate that enabled heat.

(Cherry-picked from 201c01f19b)

Change-Id: I405423bdc9ba8dd9b30fce6fdceacccf662d5da3

.gitignore

@@ -1,13 +1,9 @@
 *~
 .*.sw?
 *.log
-*-log
-*.log.*
-*-log.*
+*.log.[1-9]
 *.pem
-*.pyc
 .localrc.auto
-.localrc.password
 .prereqs
 .tox
 .stackenv
@@ -15,28 +11,16 @@ accrc
 doc/files
 doc/build
 files/*.gz
-files/*.vmdk
-files/*.rpm
-files/*.rpm.*
-files/*.deb
-files/*.deb.*
 files/*.qcow2
 files/*.img
 files/images
 files/pip-*
 files/get-pip.py*
 files/ir-deploy*
-files/ironic-inspector*
-files/etcd*
-/local.conf
+local.conf
 local.sh
 localrc
 proto
 shocco
 src
 stack-screenrc
-userrc_early
-AUTHORS
-ChangeLog
-tools/dbcounter/build/
-tools/dbcounter/dbcounter.egg-info/

.gitreview

@@ -1,4 +1,5 @@
 [gerrit]
-host=review.opendev.org
+host=review.openstack.org
 port=29418
-project=openstack/devstack.git
+project=openstack-dev/devstack.git
+defaultbranch=stable/liberty

CONTRIBUTING.rst

@@ -1,19 +0,0 @@
-The source repository for this project can be found at:
-
-   https://opendev.org/openstack/devstack
-
-Pull requests submitted through GitHub are not monitored.
-
-To start contributing to OpenStack, follow the steps in the contribution guide
-to set up and use Gerrit:
-
-   https://docs.openstack.org/contributors/code-and-documentation/quick-start.html
-
-Bugs should be filed on Launchpad:
-
-   https://bugs.launchpad.net/devstack
-
-For more specific information about contributing to this repository, see the
-Devstack contributor guide:
-
-   https://docs.openstack.org/devstack/latest/contributor/contributing.html

HACKING.rst

@@ -10,8 +10,8 @@ and so is limited to Bash (version 4 and up) and compatible shells.
 Shell script was chosen because it best illustrates the steps used to
 set up and interact with OpenStack components.
 
-DevStack's official repository is located on opendev.org at
-https://opendev.org/openstack/devstack.  Besides the master branch that
+DevStack's official repository is located on git.openstack.org at
+https://git.openstack.org/openstack-dev/devstack.  Besides the master branch that
 tracks the OpenStack trunk branches a separate branch is maintained for all
 OpenStack releases starting with Diablo (stable/diablo).
 
@@ -20,13 +20,13 @@ in `How To Contribute`__ in the OpenStack wiki.  `DevStack's LaunchPad project`_
 contains the usual links for blueprints, bugs, etc.
 
 __ contribute_
-.. _contribute: https://docs.openstack.org/infra/manual/developers.html
+.. _contribute: http://docs.openstack.org/infra/manual/developers.html
 
 __ lp_
-.. _lp: https://launchpad.net/devstack
+.. _lp: https://launchpad.net/~devstack
 
 The `Gerrit review
-queue <https://review.opendev.org/#/q/project:openstack/devstack>`__
+queue <https://review.openstack.org/#/q/project:openstack-dev/devstack,n,z>`__
 is used for all commits.
 
 The primary script in DevStack is ``stack.sh``, which performs the bulk of the
@@ -47,7 +47,12 @@ The DevStack repo generally keeps all of the primary scripts at the root
 level.
 
 ``doc`` - Contains the Sphinx source for the documentation.
-A complete doc build can be run with ``tox -edocs``.
+``tools/build_docs.sh`` is used to generate the HTML versions of the
+DevStack scripts.  A complete doc build can be run with ``tox -edocs``.
+
+``exercises`` - Contains the test scripts used to sanity-check and
+demonstrate some OpenStack functions. These scripts know how to exit
+early or skip services that are not enabled.
 
 ``extras.d`` - Contains the dispatch scripts called by the hooks in
 ``stack.sh``, ``unstack.sh`` and ``clean.sh``. See :doc:`the plugins
@@ -74,7 +79,8 @@ of test of specific fragile functions in the ``functions`` and
 
 ``tools`` - Contains a collection of stand-alone scripts. While these
 may reference the top-level DevStack configuration they can generally be
-run alone.
+run alone. There are also some sub-directories to support specific
+environments such as XenServer.
 
 
 Scripts
@@ -144,8 +150,8 @@ follows:
 * Global configuration that may be referenced in ``local.conf``, i.e. ``DEST``, ``DATA_DIR``
 * Global service configuration like ``ENABLED_SERVICES``
 * Variables used by multiple services that do not have a clear owner, i.e.
-  ``VOLUME_BACKING_FILE_SIZE`` (nova-compute and cinder) or
-  ``PUBLIC_NETWORK_NAME`` (only neutron but formerly nova-network too)
+  ``VOLUME_BACKING_FILE_SIZE`` (nova-compute, nova-volumes and cinder) or
+  ``PUBLIC_NETWORK_NAME`` (nova-network and neutron)
 * Variables that can not be cleanly declared in a project file due to
   dependency ordering, i.e. the order of sourcing the project files can
   not be changed for other reasons but the earlier file needs to dereference a
@@ -162,7 +168,7 @@ Documentation
 
 The DevStack repo now contains all of the static pages of devstack.org in
 the ``doc/source`` directory. The OpenStack CI system rebuilds the docs after every
-commit and updates devstack.org (now a redirect to https://docs.openstack.org/devstack/latest/).
+commit and updates devstack.org (now a redirect to docs.openstack.org/developer/devstack).
 
 All of the scripts are processed with shocco_ to render them with the comments
 as text describing the script below.  For this reason we tend to be a little
@@ -177,6 +183,89 @@ The complete docs build is also handled with <code>tox -edocs</code> per the
 OpenStack project standard.
 
 
+Exercises
+---------
+
+The scripts in the exercises directory are meant to 1) perform basic operational
+checks on certain aspects of OpenStack; and b) document the use of the
+OpenStack command-line clients.
+
+In addition to the guidelines above, exercise scripts MUST follow the structure
+outlined here.  ``swift.sh`` is perhaps the clearest example of these guidelines.
+These scripts are executed serially by ``exercise.sh`` in testing situations.
+
+* Begin and end with a banner that stands out in a sea of script logs to aid
+  in debugging failures, particularly in automated testing situations.  If the
+  end banner is not displayed, the script ended prematurely and can be assumed
+  to have failed.
+
+  ::
+
+    echo "**************************************************"
+    echo "Begin DevStack Exercise: $0"
+    echo "**************************************************"
+    ...
+    set +o xtrace
+    echo "**************************************************"
+    echo "End DevStack Exercise: $0"
+    echo "**************************************************"
+
+* The scripts will generally have the shell ``xtrace`` attribute set to display
+  the actual commands being executed, and the ``errexit`` attribute set to exit
+  the script on non-zero exit codes::
+
+    # This script exits on an error so that errors don't compound and you see
+    # only the first error that occurred.
+    set -o errexit
+
+    # Print the commands being run so that we can see the command that triggers
+    # an error.  It is also useful for following allowing as the install occurs.
+    set -o xtrace
+
+* Settings and configuration are stored in ``exerciserc``, which must be
+  sourced after ``openrc`` or ``stackrc``::
+
+    # Import exercise configuration
+    source $TOP_DIR/exerciserc
+
+* There are a couple of helper functions in the common ``functions`` sub-script
+  that will check for non-zero exit codes and unset environment variables and
+  print a message and exit the script.  These should be called after most client
+  commands that are not otherwise checked to short-circuit long timeouts
+  (instance boot failure, for example)::
+
+    swift post $CONTAINER
+    die_if_error "Failure creating container $CONTAINER"
+
+    FLOATING_IP=`euca-allocate-address | cut -f2`
+    die_if_not_set FLOATING_IP "Failure allocating floating IP"
+
+* If you want an exercise to be skipped when for example a service wasn't
+  enabled for the exercise to be run, you can exit your exercise with the
+  special exitcode 55 and it will be detected as skipped.
+
+* The exercise scripts should only use the various OpenStack client binaries to
+  interact with OpenStack.  This specifically excludes any ``*-manage`` tools
+  as those assume direct access to configuration and databases, as well as direct
+  database access from the exercise itself.
+
+* If specific configuration needs to be present for the exercise to complete,
+  it should be staged in ``stack.sh``, or called from ``stack.sh`` (see
+  ``files/keystone_data.sh`` for an example of this).
+
+* The ``OS_*`` environment variables should be the only ones used for all
+  authentication to OpenStack clients as documented in the CLIAuth_ wiki page.
+
+.. _CLIAuth: http://wiki.openstack.org/CLIAuth
+
+* The exercise MUST clean up after itself if successful.  If it is not successful,
+  it is assumed that state will be left behind; this allows a chance for developers
+  to look around and attempt to debug the problem.  The exercise SHOULD clean up
+  or graciously handle possible artifacts left over from previous runs if executed
+  again.  It is acceptable to require a reboot or even a re-install of DevStack
+  to restore a clean test environment.
+
+
 Bash Style Guidelines
 ~~~~~~~~~~~~~~~~~~~~~
 DevStack defines a bash set of best practices for maintaining large
@@ -188,7 +277,7 @@ to enforce basic guidelines, similar to pep8 and flake8 tools for Python. The
 list below is not complete for what bashate checks, nor is it all checked
 by bashate.  So many lines of code, so little time.
 
-.. _bashate: https://pypi.org/project/bashate/
+.. _bashate: https://pypi.python.org/pypi/bashate
 
 Whitespace Rules
 ----------------
@@ -234,13 +323,13 @@ Variables and Functions
 
 
 Review Criteria
----------------
+===============
 
 There are some broad criteria that will be followed when reviewing
 your change
 
 * **Is it passing tests** -- your change will not be reviewed
-  thoroughly unless the official CI has run successfully against it.
+  throughly unless the official CI has run successfully against it.
 
 * **Does this belong in DevStack** -- DevStack reviewers have a
   default position of "no" but are ready to be convinced by your
@@ -274,25 +363,5 @@ your change
   even years from now -- why we were motivated to make a change at the
   time.
 
-
-Making Changes, Testing, and CI
--------------------------------
-
-Changes to Devstack are tested by automated continuous integration jobs
-that run on a variety of Linux Distros using a handful of common
-configurations. What this means is that every change to Devstack is
-self testing. One major benefit of this is that developers do not
-typically need to add new non voting test jobs to add features to
-Devstack. Instead the features can be added, then if testing passes
-with the feature enabled the change is ready to merge (pending code
-review).
-
-A concrete example of this was the switch from screen based service
-management to systemd based service management. No new jobs were
-created for this. Instead the features were added to devstack, tested
-locally and in CI using a change that enabled the feature, then once
-the enabling change was passing and the new behavior communicated and
-documented it was merged.
-
-Using this process has been proven to be effective and leads to
-quicker implementation of desired features.
+* **Reviewers** -- please see ``MAINTAINERS.rst`` for a list of people
+  that should be added to reviews of various sub-systems.

MAINTAINERS.rst

@@ -0,0 +1,92 @@
+MAINTAINERS
+===========
+
+
+Overview
+--------
+
+The following is a list of people known to have interests in
+particular areas or sub-systems of devstack.
+
+It is a rather general guide intended to help seed the initial
+reviewers list of a change.  A +1 on a review from someone identified
+as being a maintainer of its affected area is a very positive flag to
+the core team for the veracity of the change.
+
+The ``devstack-core`` group can still be added to all reviews.
+
+
+Format
+~~~~~~
+
+The format of the file is the name of the maintainer and their
+gerrit-registered email.
+
+
+Maintainers
+-----------
+
+.. contents:: :local:
+
+
+Ceph
+~~~~
+
+* Sebastien Han <sebastien.han@enovance.com>
+
+Cinder
+~~~~~~
+
+Fedora/CentOS/RHEL
+~~~~~~~~~~~~~~~~~~
+
+* Ian Wienand <iwienand@redhat.com>
+
+Neutron
+~~~~~~~
+
+MidoNet
+~~~~~~~
+
+* Jaume Devesa <devvesa@gmail.com>
+* Ryu Ishimoto <ryu@midokura.com>
+* YAMAMOTO Takashi <yamamoto@midokura.com>
+
+OpenDaylight
+~~~~~~~~~~~~
+
+* Kyle Mestery <mestery@mestery.com>
+
+OpenFlow Agent (ofagent)
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+* YAMAMOTO Takashi <yamamoto@valinux.co.jp>
+* Fumihiko Kakuma <kakuma@valinux.co.jp>
+
+Swift
+~~~~~
+
+* Chmouel Boudjnah <chmouel@enovance.com>
+
+SUSE
+~~~~
+
+* Ralf Haferkamp <rhafer@suse.de>
+* Vincent Untz <vuntz@suse.com>
+
+Tempest
+~~~~~~~
+
+Xen
+~~~
+* Bob Ball <bob.ball@citrix.com>
+
+Zaqar (Marconi)
+~~~~~~~~~~~~~~~
+
+* Flavio Percoco <flaper87@gmail.com>
+* Malini Kamalambal <malini.kamalambal@rackspace.com>
+
+Oracle Linux
+~~~~~~~~~~~~
+* Wiekus Beukes <wiekus.beukes@oracle.com>

Makefile

@@ -15,7 +15,7 @@
 DEST=/opt/stack
 
 all:
-	@echo "This just saved you from a terrible mistake!"
+	echo "This just saved you from a terrible mistake!"
 
 # Do Some Work
 stack:

README.md

@@ -1,10 +1,8 @@
-DevStack is a set of scripts and utilities to quickly deploy an OpenStack cloud
-from git source trees.
+DevStack is a set of scripts and utilities to quickly deploy an OpenStack cloud.
 
-Goals
-=====
+# Goals
 
-* To quickly build dev OpenStack environments in a clean Ubuntu or RockyLinux
+* To quickly build dev OpenStack environments in a clean Ubuntu or Fedora
   environment
 * To describe working configurations of OpenStack (which code branches
   work together?  what do config files look like for those branches?)
@@ -15,22 +13,21 @@ Goals
 * To provide an environment for the OpenStack CI testing on every commit
   to the projects
 
-Read more at https://docs.openstack.org/devstack/latest
+Read more at http://docs.openstack.org/developer/devstack
 
 IMPORTANT: Be sure to carefully read `stack.sh` and any other scripts you
 execute before you run them, as they install software and will alter your
 networking configuration.  We strongly recommend that you run `stack.sh`
 in a clean and disposable vm when you are first getting started.
 
-Versions
-========
+# Versions
 
 The DevStack master branch generally points to trunk versions of OpenStack
 components.  For older, stable versions, look for branches named
 stable/[release] in the DevStack repo.  For example, you can do the
-following to create a Zed OpenStack cloud::
+following to create a juno OpenStack cloud:
 
-    git checkout stable/zed
+    git checkout stable/juno
     ./stack.sh
 
 You can also pick specific OpenStack project releases by setting the appropriate
@@ -38,11 +35,10 @@ You can also pick specific OpenStack project releases by setting the appropriate
 `stackrc` for the default set).  Usually just before a release there will be
 milestone-proposed branches that need to be tested::
 
-    GLANCE_REPO=https://opendev.org/openstack/glance.git
+    GLANCE_REPO=git://git.openstack.org/openstack/glance.git
     GLANCE_BRANCH=milestone-proposed
 
-Start A Dev Cloud
-=================
+# Start A Dev Cloud
 
 Installing in a dedicated disposable VM is safer than installing on your
 dev machine!  Plus you can pick one of the supported Linux distros for
@@ -55,18 +51,24 @@ When the script finishes executing, you should be able to access OpenStack
 endpoints, like so:
 
 * Horizon: http://myhost/
-* Keystone: http://myhost/identity/v3/
+* Keystone: http://myhost:5000/v2.0/
 
 We also provide an environment file that you can use to interact with your
-cloud via CLI::
+cloud via CLI:
 
     # source openrc file to load your environment with OpenStack CLI creds
     . openrc
     # list instances
-    openstack server list
+    nova list
 
-DevStack Execution Environment
-==============================
+If the EC2 API is your cup-o-tea, you can create credentials and use euca2ools:
+
+    # source eucarc to generate EC2 credentials and set up the environment
+    . eucarc
+    # list instances using ec2 api
+    euca-describe-instances
+
+# DevStack Execution Environment
 
 DevStack runs rampant over the system it runs on, installing things and
 uninstalling other things.  Running this on a system you care about is a recipe
@@ -86,12 +88,10 @@ check it out to see what DevStack's expectations are for the account
 it runs under.  Many people simply use their usual login (the default
 'ubuntu' login on a UEC image for example).
 
-Customizing
-===========
+# Customizing
 
 DevStack can be extensively configured via the configuration file
 `local.conf`.  It is likely that you will need to provide and modify
 this file if you want anything other than the most basic setup.  Start
-by reading the `configuration guide
-<https://docs.openstack.org/devstack/latest/configuration.html>`_
-for details of the configuration file and the many available options.
+by reading the [configuration guide](doc/source/configuration.rst) for
+details of the configuration file and the many available options.

clean.sh

@@ -26,7 +26,7 @@ if [[ -r $TOP_DIR/.stackenv ]]; then
 fi
 
 # Determine what system we are running on.  This provides ``os_VENDOR``,
-# ``os_RELEASE``, ``os_PACKAGE``, ``os_CODENAME``
+# ``os_RELEASE``, ``os_UPDATE``, ``os_PACKAGE``, ``os_CODENAME``
 # and ``DISTRO``
 GetDistro
 
@@ -46,12 +46,12 @@ source $TOP_DIR/lib/horizon
 source $TOP_DIR/lib/keystone
 source $TOP_DIR/lib/glance
 source $TOP_DIR/lib/nova
-source $TOP_DIR/lib/placement
 source $TOP_DIR/lib/cinder
 source $TOP_DIR/lib/swift
-source $TOP_DIR/lib/neutron
+source $TOP_DIR/lib/heat
+source $TOP_DIR/lib/neutron-legacy
+source $TOP_DIR/lib/ironic
 
-set -o xtrace
 
 # Extras Source
 # --------------
@@ -63,8 +63,13 @@ if [[ -d $TOP_DIR/extras.d ]]; then
     done
 fi
 
-# Let unstack.sh do its thing first
-$TOP_DIR/unstack.sh --all
+# See if there is anything running...
+# need to adapt when run_service is merged
+SESSION=$(screen -ls | awk '/[0-9].stack/ { print $1 }')
+if [[ -n "$SESSION" ]]; then
+    # Let unstack.sh do its thing first
+    $TOP_DIR/unstack.sh --all
+fi
 
 # Run extras
 # ==========
@@ -87,10 +92,8 @@ cleanup_cinder || /bin/true
 cleanup_glance
 cleanup_keystone
 cleanup_nova
-cleanup_placement
 cleanup_neutron
 cleanup_swift
-cleanup_horizon
 
 if is_service_enabled ldap; then
     cleanup_ldap
@@ -102,7 +105,7 @@ if is_service_enabled nova && [[ -r $NOVA_PLUGINS/hypervisor-$VIRT_DRIVER ]]; th
 fi
 
 # Clean out /etc
-sudo rm -rf /etc/keystone /etc/glance /etc/nova /etc/cinder /etc/swift /etc/neutron /etc/openstack/
+sudo rm -rf /etc/keystone /etc/glance /etc/nova /etc/cinder /etc/swift /etc/heat /etc/neutron
 
 # Clean out tgt
 sudo rm -f /etc/tgt/conf.d/*
@@ -112,7 +115,7 @@ cleanup_rpc_backend
 cleanup_database
 
 # Clean out data and status
-sudo rm -rf $DATA_DIR $DEST/status $DEST/async
+sudo rm -rf $DATA_DIR $DEST/status
 
 # Clean out the log file and log directories
 if [[ -n "$LOGFILE" ]] && [[ -f "$LOGFILE" ]]; then
@@ -121,11 +124,9 @@ fi
 if [[ -n "$LOGDIR" ]] && [[ -d "$LOGDIR" ]]; then
     sudo rm -rf $LOGDIR
 fi
-
-# Clean out the systemd unit files.
-sudo find $SYSTEMD_DIR -type f -name '*devstack@*service' -delete
-# Make systemd aware of the deletion.
-$SYSTEMCTL daemon-reload
+if [[ -n "$SCREEN_LOGDIR" ]] && [[ -d "$SCREEN_LOGDIR" ]]; then
+    sudo rm -rf $SCREEN_LOGDIR
+fi
 
 # Clean up venvs
 DIRS_TO_CLEAN="$WHEELHOUSE ${PROJECT_VENV[@]} .config/openstack"
@@ -133,16 +134,9 @@ rm -rf $DIRS_TO_CLEAN
 
 # Clean up files
 
-FILES_TO_CLEAN=".localrc.auto .localrc.password "
-FILES_TO_CLEAN+="docs/files docs/html shocco/ "
-FILES_TO_CLEAN+="stack-screenrc test*.conf* test.ini* "
+FILES_TO_CLEAN=".localrc.auto docs/files docs/html shocco/ stack-screenrc test*.conf* test.ini*"
 FILES_TO_CLEAN+=".stackenv .prereqs"
 
 for file in $FILES_TO_CLEAN; do
     rm -rf $TOP_DIR/$file
 done
-
-rm -rf ~/.config/openstack
-
-# Clear any fstab entries made
-sudo sed -i '/.*comment=devstack-.*/ d' /etc/fstab

data/devstack-plugins-registry.header

@@ -1,21 +0,0 @@
-.. Note to patch submitters:
-
-   # ============================= #
-   # THIS FILE IS AUTOGENERATED !  #
-   # ============================= #
-
-   ** Plugins are found automatically and added to this list **
-
-   This file is created by a periodic proposal job.  You should not
-   edit this file.
-
-   You should edit the files data/devstack-plugins-registry.footer
-   data/devstack-plugins-registry.header to modify this text.
-
-==========================
- DevStack Plugin Registry
-==========================
-
-The following list is an automatically-generated collection of
-available DevStack plugins.  This includes, but is not limited to,
-official OpenStack projects.

doc/requirements.txt

@@ -1,7 +0,0 @@
-pbr>=2.0.0,!=2.1.0
-
-Pygments
-docutils
-sphinx>=2.0.0,!=2.1.0 # BSD
-openstackdocstheme>=2.2.1 # Apache-2.0
-zuul-sphinx>=0.2.0

doc/source/assets/local.conf

@@ -1 +0,0 @@
-../../../samples/local.conf

doc/source/changes.rst

@@ -0,0 +1,12 @@
+=======
+Changes
+=======
+
+Recent Changes What's been happening?
+=====================================
+
+These are the commits to DevStack for the last six months. For the
+complete list see `the DevStack project in
+Gerrit <https://review.openstack.org/#/q/status:merged+project:openstack-dev/devstack,n,z>`__.
+
+%GIT_LOG%

doc/source/conf.py

@@ -11,6 +11,9 @@
 # All configuration values have a default; values that are commented out
 # serve to show the default.
 
+import sys
+import os
+
 # If extensions (or modules to document with autodoc) are in another directory,
 # add these directories to sys.path here. If the directory is relative to the
 # documentation root, use os.path.abspath to make it absolute, like shown here.
@@ -23,22 +26,7 @@
 
 # Add any Sphinx extension module names here, as strings. They can be extensions
 # coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
-extensions = [
-    'sphinx.ext.autodoc',
-    'zuul_sphinx',
-    'openstackdocstheme',
-]
-
-# openstackdocstheme options
-openstackdocs_repo_name = 'openstack/devstack'
-openstackdocs_pdf_link = True
-openstackdocs_bug_project = 'devstack'
-openstackdocs_bug_tag = ''
-openstackdocs_auto_name = False
-# This repo is not tagged, so don't set versions
-openstackdocs_auto_version = False
-version = ''
-release = ''
+extensions = [ 'oslosphinx', 'sphinxcontrib.blockdiag', 'sphinxcontrib.nwdiag' ]
 
 todo_include_todos = True
 
@@ -87,7 +75,7 @@ add_module_names = False
 show_authors = False
 
 # The name of the Pygments (syntax highlighting) style to use.
-pygments_style = 'native'
+pygments_style = 'sphinx'
 
 # A list of ignored prefixes for module index sorting.
 modindex_common_prefix = ['DevStack-doc.']
@@ -99,7 +87,7 @@ man_pages = []
 
 # The theme to use for HTML and HTML Help pages.  See the documentation for
 # a list of builtin themes.
-html_theme = 'openstackdocs'
+html_theme = 'nature'
 
 # Theme options are theme-specific and customize the look and feel of a theme
 # further.  For a list of options available for each theme, see the
@@ -125,6 +113,11 @@ html_theme = 'openstackdocs'
 # pixels large.
 #html_favicon = None
 
+# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
+# using the given strftime format.
+git_cmd = "git log --pretty=format:'%ad, commit %h' --date=local -n1"
+html_last_updated_fmt = os.popen(git_cmd).read()
+
 # If true, SmartyPants will be used to convert quotes and dashes to
 # typographically correct entities.
 #html_use_smartypants = True
@@ -168,10 +161,21 @@ htmlhelp_basename = 'DevStack-doc'
 
 # -- Options for LaTeX output --------------------------------------------------
 
+latex_elements = {
+# The paper size ('letterpaper' or 'a4paper').
+#'papersize': 'letterpaper',
+
+# The font size ('10pt', '11pt' or '12pt').
+#'pointsize': '10pt',
+
+# Additional stuff for the LaTeX preamble.
+#'preamble': '',
+}
+
 # Grouping the document tree into LaTeX files. List of tuples
 # (source start file, target name, title, author, documentclass [howto/manual]).
 latex_documents = [
-  ('index', 'doc-devstack.tex', u'DevStack Docs',
+  ('index', 'DevStack-doc.tex', u'DevStack Docs',
    u'OpenStack DevStack Team', 'manual'),
 ]
 

doc/source/configuration.rst

@@ -36,12 +36,14 @@ The defined phases are:
 
 -  **local** - extracts ``localrc`` from ``local.conf`` before
    ``stackrc`` is sourced
+-  **pre-install** - runs after the system packages are installed but
+   before any of the source repositories are installed
+-  **install** - runs immediately after the repo installations are
+   complete
 -  **post-config** - runs after the layer 2 services are configured and
    before they are started
 -  **extra** - runs after services are started and before any files in
    ``extra.d`` are executed
--  **post-extra** - runs after files in ``extra.d`` are executed
--  **test-config** - runs after tempest (and plugins) are configured
 
 The file is processed strictly in sequence; meta-sections may be
 specified more than once but if any settings are duplicated the last to
@@ -59,12 +61,13 @@ appear in the file will be used.
 A specific meta-section ``local|localrc`` is used to provide a default
 ``localrc`` file (actually ``.localrc.auto``). This allows all custom
 settings for DevStack to be contained in a single file. If ``localrc``
-exists it will be used instead to preserve backward-compatibility.
+exists it will be used instead to preserve backward-compatibility. More
+details on the :doc:`contents of local.conf <local.conf>` are available.
 
 ::
 
     [[local|localrc]]
-    IPV4_ADDRS_SAFE_TO_USE=10.254.1.0/24
+    FIXED_RANGE=10.254.1.0/24
     ADMIN_PASSWORD=speciale
     LOGFILE=$DEST/logs/stack.sh.log
 
@@ -80,76 +83,6 @@ Also note that the ``localrc`` section is sourced as a shell script
 fragment and MUST conform to the shell requirements, specifically no
 whitespace around ``=`` (equals).
 
-openrc
-======
-
-``openrc`` configures login credentials suitable for use with the
-OpenStack command-line tools. ``openrc`` sources ``stackrc`` at the
-beginning (which in turn sources the ``localrc`` section of
-``local.conf``) in order to pick up ``HOST_IP`` and/or ``SERVICE_HOST``
-to use in the endpoints. The values shown below are the default values.
-
-OS\_PROJECT\_NAME (OS\_TENANT\_NAME)
-    Keystone has
-    standardized the term *project* as the entity that owns resources. In
-    some places references still exist to the previous term
-    *tenant* for this use. Also, *project\_name* is preferred to
-    *project\_id*.  OS\_TENANT\_NAME remains supported for compatibility
-    with older tools.
-
-    ::
-
-        OS_PROJECT_NAME=demo
-
-OS\_USERNAME
-    In addition to the owning entity (project), OpenStack calls the entity
-    performing the action *user*.
-
-    ::
-
-        OS_USERNAME=demo
-
-OS\_PASSWORD
-    Keystone's default authentication requires a password be provided.
-    The usual cautions about putting passwords in environment variables
-    apply, for most DevStack uses this may be an acceptable tradeoff.
-
-    ::
-
-        OS_PASSWORD=secret
-
-HOST\_IP, SERVICE\_HOST
-    Set API endpoint host using ``HOST_IP``. ``SERVICE_HOST`` may also
-    be used to specify the endpoint, which is convenient for some
-    ``local.conf`` configurations. Typically, ``HOST_IP`` is set in the
-    ``localrc`` section.
-
-    ::
-
-        HOST_IP=127.0.0.1
-        SERVICE_HOST=$HOST_IP
-
-OS\_AUTH\_URL
-    Authenticating against an OpenStack cloud using Keystone returns a
-    *Token* and *Service Catalog*. The catalog contains the endpoints
-    for all services the user/tenant has access to - including Nova,
-    Glance, Keystone and Swift.
-
-    ::
-
-        OS_AUTH_URL=http://$SERVICE_HOST:5000/v3.0
-
-KEYSTONECLIENT\_DEBUG, NOVACLIENT\_DEBUG
-    Set command-line client log level to ``DEBUG``. These are commented
-    out by default.
-
-    ::
-
-        # export KEYSTONECLIENT_DEBUG=1
-        # export NOVACLIENT_DEBUG=1
-
-
-
 .. _minimal-configuration:
 
 Minimal Configuration
@@ -162,28 +95,26 @@ values that most often need to be set.
 
 -  no logging
 -  pre-set the passwords to prevent interactive prompts
--  move network ranges away from the local network (``IPV4_ADDRS_SAFE_TO_USE``
-   and ``FLOATING_RANGE``, commented out below)
+-  move network ranges away from the local network (``FIXED_RANGE`` and
+   ``FLOATING_RANGE``, commented out below)
 -  set the host IP if detection is unreliable (``HOST_IP``, commented
    out below)
 
 ::
 
     [[local|localrc]]
-    ADMIN_PASSWORD=secret
+    ADMIN_PASSWORD=secrete
     DATABASE_PASSWORD=$ADMIN_PASSWORD
     RABBIT_PASSWORD=$ADMIN_PASSWORD
     SERVICE_PASSWORD=$ADMIN_PASSWORD
-    #IPV4_ADDRS_SAFE_TO_USE=172.31.1.0/24
+    SERVICE_TOKEN=a682f596-76f3-11e3-b3b2-e716f9080d50
+    #FIXED_RANGE=172.31.1.0/24
     #FLOATING_RANGE=192.168.20.0/25
     #HOST_IP=10.3.4.5
 
 If the ``*_PASSWORD`` variables are not set here you will be prompted to
 enter values for them by ``stack.sh``.
 
-.. warning:: Only use alphanumeric characters in your passwords, as some
-   services fail to work when using special characters.
-
 The network ranges must not overlap with any networks in use on the
 host. Overlap is not uncommon as RFC-1918 'private' ranges are commonly
 used for both the local networking and Nova's fixed and floating ranges.
@@ -199,16 +130,13 @@ will not be set if there is no IPv6 address on the default Ethernet interface.
 Setting it here also makes it available for ``openrc`` to set ``OS_AUTH_URL``.
 ``HOST_IPV6`` is not set by default.
 
-For architecture specific configurations which differ from the x86 default
-here, see `arch-configuration`_.
-
 Historical Notes
 ================
 
 Historically DevStack obtained all local configuration and
 customizations from a ``localrc`` file.  In Oct 2013 the
 ``local.conf`` configuration method was introduced (in `review 46768
-<https://review.opendev.org/#/c/46768/>`__) to simplify this
+<https://review.openstack.org/#/c/46768/>`__) to simplify this
 process.
 
 Configuration Notes
@@ -217,34 +145,6 @@ Configuration Notes
 .. contents::
    :local:
 
-Service Repos
--------------
-
-The Git repositories used to check out the source for each service are
-controlled by a pair of variables set for each service.  ``*_REPO``
-points to the repository and ``*_BRANCH`` selects which branch to
-check out. These may be overridden in ``local.conf`` to pull source
-from a different repo for testing, such as a Gerrit branch
-proposal. ``GIT_BASE`` points to the primary repository server.
-
-::
-
-    NOVA_REPO=$GIT_BASE/openstack/nova.git
-    NOVA_BRANCH=master
-
-To pull a branch directly from Gerrit, get the repo and branch from
-the Gerrit review page::
-
-    git fetch https://review.opendev.org/openstack/nova \
-        refs/changes/50/5050/1 && git checkout FETCH_HEAD
-
-The repo is the stanza following ``fetch`` and the branch is the
-stanza following that::
-
-    NOVA_REPO=https://review.opendev.org/openstack/nova
-    NOVA_BRANCH=refs/changes/50/5050/1
-
-
 Installation Directory
 ----------------------
 
@@ -255,15 +155,13 @@ By setting it early in the ``localrc`` section you can reference it in
 later variables.  It can be useful to set it even though it is not
 changed from the default value.
 
-::
+    ::
 
-    DEST=/opt/stack
+        DEST=/opt/stack
 
 Logging
 -------
 
-.. _enable_logging:
-
 Enable Logging
 ~~~~~~~~~~~~~~
 
@@ -273,45 +171,54 @@ runs. It can be sent to a file in addition to the console by setting
 timestamp will be appended to the given filename for each run of
 ``stack.sh``.
 
-::
+    ::
 
-    LOGFILE=$DEST/logs/stack.sh.log
+        LOGFILE=$DEST/logs/stack.sh.log
 
 Old log files are cleaned automatically if ``LOGDAYS`` is set to the
 number of days of old log files to keep.
 
-::
+    ::
 
-    LOGDAYS=2
+        LOGDAYS=1
 
-Some coloring is used during the DevStack runs to make it easier to
-see what is going on. This can be disabled with::
+The some of the project logs (Nova, Cinder, etc) will be colorized by
+default (if ``SYSLOG`` is not set below); this can be turned off by
+setting ``LOG_COLOR`` to ``False``.
 
-    LOG_COLOR=False
+    ::
 
-When using the logfile, by default logs are sent to the console and
-the file.  You can set ``VERBOSE`` to ``false`` if you only wish the
-logs to be sent to the file (this may avoid having double-logging in
-some cases where you are capturing the script output and the log
-files).  If ``VERBOSE`` is ``true`` you can additionally set
-``VERBOSE_NO_TIMESTAMP`` to avoid timestamps being added to each
-output line sent to the console.  This can be useful in some
-situations where the console output is being captured by a runner or
-framework (e.g. Ansible) that adds its own timestamps.  Note that the
-log lines sent to the ``LOGFILE`` will still be prefixed with a
-timestamp.
+        LOG_COLOR=False
 
 Logging the Service Output
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-By default, services run under ``systemd`` and are natively logging to
-the systemd journal.
+DevStack will log the ``stdout`` output of the services it starts.
+When using ``screen`` this logs the output in the screen windows to a
+file.  Without ``screen`` this simply redirects stdout of the service
+process to a file in ``LOGDIR``.
 
-To query the logs use the ``journalctl`` command, such as::
+    ::
 
-  sudo journalctl --unit devstack@*
+        LOGDIR=$DEST/logs
+
+*Note the use of ``DEST`` to locate the main install directory; this
+is why we suggest setting it in ``local.conf``.*
+
+Enabling Syslog
+~~~~~~~~~~~~~~~
+
+Logging all services to a single syslog can be convenient. Enable
+syslogging by setting ``SYSLOG`` to ``True``. If the destination log
+host is not localhost ``SYSLOG_HOST`` and ``SYSLOG_PORT`` can be used
+to direct the message stream to the log host.  |
+
+    ::
+
+        SYSLOG=True
+        SYSLOG_HOST=$HOST_IP
+        SYSLOG_PORT=516
 
-More examples can be found in :ref:`journalctl-examples`.
 
 Example Logging Configuration
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -319,25 +226,28 @@ Example Logging Configuration
 For example, non-interactive installs probably wish to save output to
 a file, keep service logs and disable color in the stored files.
 
-::
+   ::
 
-   [[local|localrc]]
-   DEST=/opt/stack/
-   LOGFILE=$LOGDIR/stack.sh.log
-   LOG_COLOR=False
+       [[local|localrc]]
+       DEST=/opt/stack/
+       LOGDIR=$DEST/logs
+       LOGFILE=$LOGDIR/stack.sh.log
+       LOG_COLOR=False
 
 Database Backend
 ----------------
 
 Multiple database backends are available. The available databases are defined
 in the lib/databases directory.
-``mysql`` is the default database, choose a different one by putting the
-following in the ``localrc`` section::
+`mysql` is the default database, choose a different one by putting the
+following in the `localrc` section:
 
-  disable_service mysql
-  enable_service postgresql
+   ::
 
-``mysql`` is the default database.
+      disable_service mysql
+      enable_service postgresql
+
+`mysql` is the default database.
 
 RPC Backend
 -----------
@@ -347,9 +257,10 @@ backends may be available via external plugins.  Enabling or disabling
 RabbitMQ is handled via the usual service functions and
 ``ENABLED_SERVICES``.
 
-Example disabling RabbitMQ in ``local.conf``::
+Example disabling RabbitMQ in ``local.conf``:
 
-  disable_service rabbit
+::
+    disable_service rabbit
 
 
 Apache Frontend
@@ -368,25 +279,24 @@ override toggle available that can be set in your ``local.conf``.
 
 Keystone is run under Apache with ``mod_wsgi`` by default.
 
-Example (Keystone)::
+Example (Keystone)
+
+::
 
     KEYSTONE_USE_MOD_WSGI="True"
 
-Example (Nova)::
+Example (Nova):
+
+::
 
     NOVA_USE_MOD_WSGI="True"
 
-Example (Swift)::
+Example (Swift):
+
+::
 
     SWIFT_USE_MOD_WSGI="True"
 
-Example (Heat)::
-
-    HEAT_USE_MOD_WSGI="True"
-
-Example (Cinder)::
-
-    CINDER_USE_MOD_WSGI="True"
 
 
 Libraries from Git
@@ -400,12 +310,9 @@ system you can have devstack install it from upstream, or from local
 git trees by specifying it in ``LIBS_FROM_GIT``.  Multiple libraries
 can be specified as a comma separated list.
 
-::
+   ::
 
-  LIBS_FROM_GIT=python-keystoneclient,oslo.config
-
-Setting the variable to ``ALL`` will activate the download for all
-libraries.
+      LIBS_FROM_GIT=python-keystoneclient,oslo.config
 
 Virtual Environments
 --------------------
@@ -418,9 +325,9 @@ Each entry in the ``PROJECT_VENV`` array contains the directory name
 of a venv to be used for the project.  The array index is the project
 name.  Multiple projects can use the same venv if desired.
 
-::
+  ::
 
-  PROJECT_VENV["glance"]=${GLANCE_DIR}.venv
+    PROJECT_VENV["glance"]=${GLANCE_DIR}.venv
 
 ``ADDITIONAL_VENV_PACKAGES`` is a comma-separated list of additional
 packages to be installed into each venv.  Often projects will not have
@@ -429,9 +336,10 @@ are 'optional' requirements, i.e. only needed for certain
 configurations.  By default, the enabled databases will have their
 Python bindings added when they are enabled.
 
-::
+  ::
+
+     ADDITIONAL_VENV_PACKAGES="python-foo, python-bar"
 
-  ADDITIONAL_VENV_PACKAGES="python-foo, python-bar"
 
 A clean install every time
 --------------------------
@@ -441,9 +349,9 @@ exist in ``$DEST``. ``stack.sh`` will freshen each repo on each run if
 ``RECLONE`` is set to ``yes``. This avoids having to manually remove
 repos in order to get the current branch from ``$GIT_BASE``.
 
-::
+    ::
 
-  RECLONE=yes
+        RECLONE=yes
 
 Upgrade packages installed by pip
 ---------------------------------
@@ -454,9 +362,27 @@ requirement. If ``PIP_UPGRADE`` is set to ``True`` then existing
 required Python packages will be upgraded to the most recent version
 that matches requirements.
 
-::
+    ::
+
+        PIP_UPGRADE=True
+
+
+Service Catalog Backend
+-----------------------
+
+By default DevStack uses Keystone's ``sql`` service catalog backend.
+An alternate ``template`` backend is also available, however, it does
+not support the ``service-*`` and ``endpoint-*`` commands of the
+``keystone`` CLI.  To do so requires the ``sql`` backend be enabled
+with ``KEYSTONE_CATALOG_BACKEND``:
+
+    ::
+
+        KEYSTONE_CATALOG_BACKEND=template
+
+DevStack's default configuration in ``sql`` mode is set in
+``files/keystone_data.sh``
 
-  PIP_UPGRADE=True
 
 Guest Images
 ------------
@@ -470,62 +396,42 @@ their testing-requirements in ``stack.sh``.  Setting
 these default images; in that case, you will want to populate
 ``IMAGE_URLS`` with sufficient images to satisfy testing-requirements.
 
-::
-
-  DOWNLOAD_DEFAULT_IMAGES=False
-  IMAGE_URLS="http://foo.bar.com/image.qcow,"
-  IMAGE_URLS+="http://foo.bar.com/image2.qcow"
-
-
-Instance Type
--------------
-
-``DEFAULT_INSTANCE_TYPE`` can be used to configure the default instance
-type. When this parameter is not specified, Devstack creates additional
-micro & nano flavors for really small instances to run Tempest tests.
-
-For guests with larger memory requirements, ``DEFAULT_INSTANCE_TYPE``
-should be specified in the configuration file so Tempest selects the
-default flavors instead.
-
-KVM on Power with QEMU 2.4 requires 512 MB to load the firmware -
-`QEMU 2.4 - PowerPC <https://wiki.qemu.org/ChangeLog/2.4>`__ so users
-running instances on ppc64/ppc64le can choose one of the default
-created flavors as follows:
-
-::
-
-  DEFAULT_INSTANCE_TYPE=m1.tiny
+    ::
 
+        DOWNLOAD_DEFAULT_IMAGES=False
+        IMAGE_URLS="http://foo.bar.com/image.qcow,"
+        IMAGE_URLS+="http://foo.bar.com/image2.qcow"
 
 IP Version
 ----------
 
-``IP_VERSION`` can be used to configure Neutron to create either an
-IPv4, IPv6, or dual-stack self-service project data-network by with
-either ``IP_VERSION=4``, ``IP_VERSION=6``, or ``IP_VERSION=4+6``
-respectively.
+``IP_VERSION`` can be used to configure DevStack to create either an
+IPv4, IPv6, or dual-stack tenant data-network by with either
+``IP_VERSION=4``, ``IP_VERSION=6``, or ``IP_VERSION=4+6``
+respectively.  This functionality requires that the Neutron networking
+service is enabled by setting the following options:
 
-::
+    ::
 
-  IP_VERSION=4+6
+        disable_service n-net
+        enable_service q-svc q-agt q-dhcp q-l3
 
 The following optional variables can be used to alter the default IPv6
 behavior:
 
-::
+    ::
 
-  IPV6_RA_MODE=slaac
-  IPV6_ADDRESS_MODE=slaac
-  IPV6_ADDRS_SAFE_TO_USE=fd$IPV6_GLOBAL_ID::/56
-  IPV6_PRIVATE_NETWORK_GATEWAY=fd$IPV6_GLOBAL_ID::1
+        IPV6_RA_MODE=slaac
+        IPV6_ADDRESS_MODE=slaac
+        FIXED_RANGE_V6=fd$IPV6_GLOBAL_ID::/64
+        IPV6_PRIVATE_NETWORK_GATEWAY=fd$IPV6_GLOBAL_ID::1
 
-*Note*: ``IPV6_ADDRS_SAFE_TO_USE`` and ``IPV6_PRIVATE_NETWORK_GATEWAY``
-can be configured with any valid IPv6 prefix. The default values make
-use of an auto-generated ``IPV6_GLOBAL_ID`` to comply with RFC4193.
+*Note*: ``FIXED_RANGE_V6`` and ``IPV6_PRIVATE_NETWORK_GATEWAY`` can be
+configured with any valid IPv6 prefix. The default values make use of
+an auto-generated ``IPV6_GLOBAL_ID`` to comply with RFC4193.
 
-Service IP Version
-~~~~~~~~~~~~~~~~~~
+Service Version
+~~~~~~~~~~~~~~~
 
 DevStack can enable service operation over either IPv4 or IPv6 by
 setting ``SERVICE_IP_VERSION`` to either ``SERVICE_IP_VERSION=4`` or
@@ -541,30 +447,11 @@ address.
 
 The default value for this setting is ``4``.  Dual-mode support, for
 example ``4+6`` is not currently supported.  ``HOST_IPV6`` can
-optionally be used to alter the default IPv6 address::
+optionally be used to alter the default IPv6 address
 
-  HOST_IPV6=${some_local_ipv6_address}
+    ::
 
-Tunnel IP Version
-~~~~~~~~~~~~~~~~~
-
-DevStack can enable tunnel operation over either IPv4 or IPv6 by
-setting ``TUNNEL_IP_VERSION`` to either ``TUNNEL_IP_VERSION=4`` or
-``TUNNEL_IP_VERSION=6`` respectively.
-
-When set to ``4`` Neutron will use an IPv4 address for tunnel endpoints,
-for example, ``HOST_IP``.
-
-When set to ``6`` Neutron will use an IPv6 address for tunnel endpoints,
-for example, ``HOST_IPV6``.
-
-The default value for this setting is ``4``.  Dual-mode support, for
-example ``4+6`` is not supported, as this value must match the address
-family of the local tunnel endpoint IP(v6) address.
-
-The value of ``TUNNEL_IP_VERSION`` has a direct relationship to the
-setting of ``TUNNEL_ENDPOINT_IP``, which will default to ``HOST_IP``
-when set to ``4``, and ``HOST_IPV6`` when set to ``6``.
+        HOST_IPV6=${some_local_ipv6_address}
 
 Multi-node setup
 ~~~~~~~~~~~~~~~~
@@ -586,9 +473,11 @@ Swift
 
 Swift is disabled by default.  When enabled, it is configured with
 only one replica to avoid being IO/memory intensive on a small
-VM.
+VM. When running with only one replica the account, container and
+object services will run directly in screen. The others services like
+replicator, updaters or auditor runs in background.
 
-If you would like to enable Swift you can add this to your ``localrc``
+If you would like to enable Swift you can add this to your `localrc`
 section:
 
 ::
@@ -596,7 +485,7 @@ section:
     enable_service s-proxy s-object s-container s-account
 
 If you want a minimal Swift install with only Swift and Keystone you
-can have this instead in your ``localrc`` section:
+can have this instead in your `localrc` section:
 
 ::
 
@@ -605,30 +494,41 @@ can have this instead in your ``localrc`` section:
 
 If you only want to do some testing of a real normal swift cluster
 with multiple replicas you can do so by customizing the variable
-``SWIFT_REPLICAS`` in your ``localrc`` section (usually to 3).
-
-You can manually override the ring building to use specific storage
-nodes, for example when you want to test a multinode environment. In
-this case you have to set a space-separated list of IPs in
-``SWIFT_STORAGE_IPS`` in your ``localrc`` section that should be used
-as Swift storage nodes.
-Please note that this does not create a multinode setup, it is only
-used when adding nodes to the Swift rings.
-
-::
-
-    SWIFT_STORAGE_IPS="192.168.1.10 192.168.1.11 192.168.1.12"
+`SWIFT_REPLICAS` in your `localrc` section (usually to 3).
 
 Swift S3
 ++++++++
 
-If you are enabling ``s3api`` in ``ENABLED_SERVICES`` DevStack will
-install the s3api middleware emulation. Swift will be configured to
+If you are enabling `swift3` in `ENABLED_SERVICES` DevStack will
+install the swift3 middleware emulation. Swift will be configured to
 act as a S3 endpoint for Keystone so effectively replacing the
-``nova-objectstore``.
+`nova-objectstore`.
 
-Only Swift proxy server is launched in the systemd system all other
-services are started in background and managed by ``swift-init`` tool.
+Only Swift proxy server is launched in the screen session all other
+services are started in background and managed by `swift-init` tool.
+
+Heat
+~~~~
+
+Heat is disabled by default (see `stackrc` file). To enable it
+explicitly you'll need the following settings in your `localrc`
+section
+
+::
+
+    enable_service heat h-api h-api-cfn h-api-cw h-eng
+
+Heat can also run in standalone mode, and be configured to orchestrate
+on an external OpenStack cloud. To launch only Heat in standalone mode
+you'll need the following settings in your `localrc` section
+
+::
+
+    disable_all_services
+    enable_service rabbit mysql heat h-api h-api-cfn h-api-cw h-eng
+    HEAT_STANDALONE=True
+    KEYSTONE_SERVICE_HOST=...
+    KEYSTONE_AUTH_HOST=...
 
 Tempest
 ~~~~~~~
@@ -639,7 +539,7 @@ tests can be run as follows:
 ::
 
     $ cd /opt/stack/tempest
-    $ tox -e smoke
+    $ tox -efull  tempest.scenario.test_network_basic_ops
 
 By default tempest is downloaded and the config file is generated, but the
 tempest package is not installed in the system's global site-packages (the
@@ -652,54 +552,40 @@ outside of tox. If you would like to install it add the following to your
     INSTALL_TEMPEST=True
 
 
+Xenserver
+~~~~~~~~~
+
+If you would like to use Xenserver as the hypervisor, please refer to
+the instructions in `./tools/xen/README.md`.
+
+Cells
+~~~~~
+
+`Cells <http://wiki.openstack.org/blueprint-nova-compute-cells>`__ is
+an alternative scaling option.  To setup a cells environment add the
+following to your `localrc` section:
+
+::
+
+    enable_service n-cell
+
+Be aware that there are some features currently missing in cells, one
+notable one being security groups.  The exercises have been patched to
+disable functionality not supported by cells.
+
 Cinder
 ~~~~~~
 
 The logical volume group used to hold the Cinder-managed volumes is
-set by ``VOLUME_GROUP_NAME``, the logical volume name prefix is set with
+set by ``VOLUME_GROUP``, the logical volume name prefix is set with
 ``VOLUME_NAME_PREFIX`` and the size of the volume backing file is set
 with ``VOLUME_BACKING_FILE_SIZE``.
 
-::
+    ::
 
-  VOLUME_GROUP_NAME="stack-volumes"
-  VOLUME_NAME_PREFIX="volume-"
-  VOLUME_BACKING_FILE_SIZE=24G
-
-When running highly concurrent tests, the default per-project quotas
-for volumes, backups, or snapshots may be too small.  These can be
-adjusted by setting ``CINDER_QUOTA_VOLUMES``, ``CINDER_QUOTA_BACKUPS``,
-or ``CINDER_QUOTA_SNAPSHOTS`` to the desired value.  (The default for
-each is 10.)
-
-DevStack's Cinder LVM configuration module currently supports both iSCSI and
-NVMe connections, and we can choose which one to use with options
-``CINDER_TARGET_HELPER``, ``CINDER_TARGET_PROTOCOL``, ``CINDER_TARGET_PREFIX``,
-and ``CINDER_TARGET_PORT``.
-
-Defaults use iSCSI with the LIO target manager::
-
-  CINDER_TARGET_HELPER="lioadm"
-  CINDER_TARGET_PROTOCOL="iscsi"
-  CINDER_TARGET_PREFIX="iqn.2010-10.org.openstack:"
-  CINDER_TARGET_PORT=3260
-
-Additionally there are 3 supported transport protocols for NVMe,
-``nvmet_rdma``, ``nvmet_tcp``, and ``nvmet_fc``, and when the ``nvmet`` target
-is selected the protocol, prefix, and port defaults will change to more
-sensible defaults for NVMe::
-
-  CINDER_TARGET_HELPER="nvmet"
-  CINDER_TARGET_PROTOCOL="nvmet_rdma"
-  CINDER_TARGET_PREFIX="nvme-subsystem-1"
-  CINDER_TARGET_PORT=4420
-
-When selecting the RDMA transport protocol DevStack will create on Cinder nodes
-a Software RoCE device on top of the ``HOST_IP_IFACE`` and if it is not defined
-then on top of the interface with IP address ``HOST_IP`` or ``HOST_IPV6``.
-
-This Soft-RoCE device will always be created on the Nova compute side since we
-cannot tell beforehand whether there will be an RDMA connection or not.
+        VOLUME_GROUP="stack-volumes"
+        VOLUME_NAME_PREFIX="volume-"
+        VOLUME_BACKING_FILE_SIZE=10250M
 
 
 Keystone
@@ -722,99 +608,8 @@ In RegionOne:
 In RegionTwo:
 
 ::
-
+   
     disable_service horizon
     KEYSTONE_SERVICE_HOST=<KEYSTONE_IP_ADDRESS_FROM_REGION_ONE>
+    KEYSTONE_AUTH_HOST=<KEYSTONE_IP_ADDRESS_FROM_REGION_ONE>
     REGION_NAME=RegionTwo
-    KEYSTONE_REGION_NAME=RegionOne
-
-In the devstack for RegionOne, we set REGION_NAME as RegionOne, so region of
-the services started in this devstack are registered as RegionOne. In devstack
-for RegionTwo, similarly, we set REGION_NAME as RegionTwo since we want
-services started in this devstack to be registered in RegionTwo. But Keystone
-service is started and registered in RegionOne, not RegionTwo, so we use
-KEYSTONE_REGION_NAME to specify the region of Keystone service.
-KEYSTONE_REGION_NAME has a default value the same as REGION_NAME thus we omit
-it in the configuration of RegionOne.
-
-Glance
-++++++
-
-The default image size quota of 1GiB may be too small if larger images
-are to be used. Change the default at setup time with:
-
-::
-
-    GLANCE_LIMIT_IMAGE_SIZE_TOTAL=5000
-
-or at runtime via:
-
-::
-
-    openstack --os-cloud devstack-system-admin registered limit set \
-      --service glance --default-limit 5000 --region RegionOne image_size_total
-
-.. _arch-configuration:
-
-Architectures
--------------
-
-The upstream CI runs exclusively on nodes with x86 architectures, but
-OpenStack supports even more architectures. Some of them need to configure
-Devstack in a certain way.
-
-KVM on s390x (IBM z Systems)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-KVM on s390x (IBM z Systems) is supported since the *Kilo* release. For
-an all-in-one setup, these minimal settings in the ``local.conf`` file
-are needed::
-
-    [[local|localrc]]
-    ADMIN_PASSWORD=secret
-    DATABASE_PASSWORD=$ADMIN_PASSWORD
-    RABBIT_PASSWORD=$ADMIN_PASSWORD
-    SERVICE_PASSWORD=$ADMIN_PASSWORD
-
-    DOWNLOAD_DEFAULT_IMAGES=False
-    IMAGE_URLS="https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-s390x-disk1.img"
-
-    # Provide a custom etcd3 binary download URL and ints sha256.
-    # The binary must be located under '/<etcd version>/etcd-<etcd-version>-linux-s390x.tar.gz'
-    # on this URL.
-    # Build instructions for etcd3: https://github.com/linux-on-ibm-z/docs/wiki/Building-etcd
-    ETCD_DOWNLOAD_URL=<your-etcd-download-url>
-    ETCD_SHA256=<your-etcd3-sha256>
-
-    enable_service n-sproxy
-    disable_service n-novnc
-
-    [[post-config|$NOVA_CONF]]
-
-    [serial_console]
-    base_url=ws://$HOST_IP:6083/  # optional
-
-Reasoning:
-
-* The default image of Devstack is x86 only, so we deactivate the download
-  with ``DOWNLOAD_DEFAULT_IMAGES``. The referenced guest image
-  in the code above (``IMAGE_URLS``) serves as an example. The list of
-  possible s390x guest images is not limited to that.
-
-* This platform doesn't support a graphical console like VNC or SPICE.
-  The technical reason is the missing framebuffer on the platform. This
-  means we rely on the substitute feature *serial console* which needs the
-  proxy service ``n-sproxy``. We also disable VNC's proxy ``n-novnc`` for
-  that reason . The configuration in the ``post-config`` section is only
-  needed if you want to use the *serial console* outside of the all-in-one
-  setup.
-
-* A link to an etcd3 binary and its sha256 needs to be provided as the
-  binary for s390x is not hosted on github like it is for other
-  architectures. For more details see
-  https://bugs.launchpad.net/devstack/+bug/1693192. Etcd3 can easily be
-  built along https://github.com/linux-on-ibm-z/docs/wiki/Building-etcd.
-
-.. note:: To run *Tempest* against this *Devstack* all-in-one, you'll need
-   to use a guest image which is smaller than 1GB when uncompressed.
-   The example image from above is bigger than that!

doc/source/contributor/contributing.rst

@@ -1,57 +0,0 @@
-============================
-So You Want to Contribute...
-============================
-
-For general information on contributing to OpenStack, please check out the
-`contributor guide <https://docs.openstack.org/contributors/>`_ to get started.
-It covers all the basics that are common to all OpenStack projects: the accounts
-you need, the basics of interacting with our Gerrit review system, how we
-communicate as a community, etc.
-
-Below will cover the more project specific information you need to get started
-with Devstack.
-
-Communication
-~~~~~~~~~~~~~
-* IRC channel ``#openstack-qa`` at OFTC.
-* Mailing list (prefix subjects with ``[qa][devstack]`` for faster responses)
-  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
-
-Contacting the Core Team
-~~~~~~~~~~~~~~~~~~~~~~~~
-Please refer to the `Devstack Core Team
-<https://review.opendev.org/#/admin/groups/50,members>`_ contacts.
-
-New Feature Planning
-~~~~~~~~~~~~~~~~~~~~
-If you want to propose a new feature please read `Feature Proposal Process`_
-Devstack features are tracked on `Launchpad BP <https://blueprints.launchpad.net/devstack>`_.
-
-Task Tracking
-~~~~~~~~~~~~~
-We track our tasks in `Launchpad <https://bugs.launchpad.net/devstack>`_.
-
-Reporting a Bug
-~~~~~~~~~~~~~~~
-You found an issue and want to make sure we are aware of it? You can do so on
-`Launchpad <https://bugs.launchpad.net/devstack/+filebug>`__.
-More info about Launchpad usage can be found on `OpenStack docs page
-<https://docs.openstack.org/contributors/common/task-tracking.html#launchpad>`_
-
-Getting Your Patch Merged
-~~~~~~~~~~~~~~~~~~~~~~~~~
-All changes proposed to the Devstack require two ``Code-Review +2`` votes from
-Devstack core reviewers before one of the core reviewers can approve the patch
-by giving ``Workflow +1`` vote. There are 2 exceptions, approving patches to
-unblock the gate and patches that do not relate to the Devstack's core logic,
-like for example old job cleanups, can be approved by single core reviewers.
-
-Project Team Lead Duties
-~~~~~~~~~~~~~~~~~~~~~~~~
-All common PTL duties are enumerated in the `PTL guide
-<https://docs.openstack.org/project-team-guide/ptl.html>`_.
-
-The Release Process for QA is documented in `QA Release Process
-<https://wiki.openstack.org/wiki/QA/releases>`_.
-
-.. _Feature Proposal Process: https://wiki.openstack.org/wiki/QA#Feature_Proposal_.26_Design_discussions

doc/source/debugging.rst

@@ -1,52 +0,0 @@
-=====================
-System-wide debugging
-=====================
-
-A lot can go wrong during a devstack run, and there are a few inbuilt
-tools to help you.
-
-dstat
------
-
-Enable the ``dstat`` service to produce performance logs during the
-devstack run.  These will be logged to the journal and also as a CSV
-file.
-
-memory_tracker
---------------
-
-The ``memory_tracker`` service periodically monitors RAM usage and
-provides consumption output when available memory is seen to be
-falling (i.e. processes are consuming memory).  It also provides
-output showing locked (unswappable) memory.
-
-file_tracker
-------------
-
-The ``file_tracker`` service periodically monitors the number of
-open files in the system.
-
-tcpdump
--------
-
-Enable the ``tcpdump`` service to run a background tcpdump.  You must
-set the ``TCPDUMP_ARGS`` variable to something suitable (there is no
-default).  For example, to trace iSCSI communication during a job in
-the OpenStack gate and copy the result into the log output, you might
-use:
-
-.. code-block:: yaml
-
-   job:
-     name: devstack-job
-     parent: devstack
-     vars:
-       devstack_services:
-         tcpdump: true
-       devstack_localrc:
-         TCPDUMP_ARGS: "-i any tcp port 3260"
-       zuul_copy_output:
-         '{{ devstack_log_dir }}/tcpdump.pcap': logs
-
-
-

doc/source/development.rst

@@ -1,117 +0,0 @@
-==========================
- 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 as `systemd` units
-named `devstack@$servicename.service`. You can see running services
-with.
-
-.. code-block:: bash
-
-   sudo systemctl status "devstack@*"
-
-To learn more about the basics of systemd, see :doc:`/systemd`
-
-Patching a Service
-==================
-
-If you want to make a quick change to a running service the easiest
-way to do that is to change the code directly in /opt/stack/$service
-and then restart the affected daemons.
-
-.. code-block:: bash
-
-   sudo systemctl restart devstack@n-cpu.service
-
-If your change impacts more than one daemon you can restart by
-wildcard as well.
-
-.. code-block:: bash
-
-   sudo systemctl restart "devstack@n-*"
-
-.. 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 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
-
-As libraries are not installed `editable` by pip, after you make any
-local changes you will need to:
-
-* cd to top of library path
-* sudo pip install -U .
-* restart all services you want to use the new library
-
-You can do that with wildcards such as
-
-.. code-block:: bash
-
-   sudo systemctl restart "devstack@n-*"
-
-which will restart all nova services.

doc/source/eucarc.rst

@@ -0,0 +1,45 @@
+=====================
+eucarc - EC2 Settings
+=====================
+
+``eucarc`` creates EC2 credentials for the current user as defined by
+``OS_TENANT_NAME:OS_USERNAME``. ``eucarc`` sources ``openrc`` at the
+beginning (which in turn sources ``stackrc`` and ``localrc``) in order
+to set credentials to create EC2 credentials in Keystone.
+
+EC2\_URL
+    Set the EC2 url for euca2ools. The endpoint is extracted from the
+    service catalog for ``OS_TENANT_NAME:OS_USERNAME``.
+
+    ::
+
+        EC2_URL=$(openstack catalog show ec2 | awk '/ publicURL: / { print $4 }')
+
+S3\_URL
+    Set the S3 endpoint for euca2ools. The endpoint is extracted from
+    the service catalog for ``OS_TENANT_NAME:OS_USERNAME``.
+
+    ::
+
+        export S3_URL=$(openstack catalog show s3 | awk '/ publicURL: / { print $4 }')
+
+EC2\_ACCESS\_KEY, EC2\_SECRET\_KEY
+    Create EC2 credentials for the current tenant:user in Keystone.
+
+    ::
+
+        CREDS=$(openstack ec2 credentials create)
+        export EC2_ACCESS_KEY=$(echo "$CREDS" | awk '/ access / { print $4 }')
+        export EC2_SECRET_KEY=$(echo "$CREDS" | awk '/ secret / { print $4 }')
+
+Certificates for Bundling
+    Euca2ools requires certificate files to enable bundle uploading. The
+    exercise script ``exercises/bundle.sh`` demonstrated retrieving
+    certificates using the Nova CLI.
+
+    ::
+
+        EC2_PRIVATE_KEY=pk.pem
+        EC2_CERT=cert.pem
+        NOVA_CERT=cacert.pem
+        EUCALYPTUS_CERT=${NOVA_CERT}

doc/source/exerciserc.rst

@@ -0,0 +1,42 @@
+==============================
+exerciserc - Exercise Settings
+==============================
+
+``exerciserc`` is used to configure settings for the exercise scripts.
+The values shown below are the default values. These can all be
+overridden by setting them in the ``localrc`` section.
+
+ACTIVE\_TIMEOUT
+    Max time to wait while vm goes from build to active state
+
+    ::
+
+        ACTIVE_TIMEOUT==30
+
+ASSOCIATE\_TIMEOUT
+    Max time to wait for proper IP association and dis-association.
+
+    ::
+
+        ASSOCIATE_TIMEOUT=15
+
+BOOT\_TIMEOUT
+    Max time till the vm is bootable
+
+    ::
+
+        BOOT_TIMEOUT=30
+
+RUNNING\_TIMEOUT
+    Max time from run instance command until it is running
+
+    ::
+
+        RUNNING_TIMEOUT=$(($BOOT_TIMEOUT + $ACTIVE_TIMEOUT))
+
+TERMINATE\_TIMEOUT
+    Max time to wait for a vm to terminate
+
+    ::
+
+        TERMINATE_TIMEOUT=30

doc/source/faq.rst

@@ -18,57 +18,6 @@ production systems.
 Your best choice is probably to choose a `distribution of OpenStack
 <https://www.openstack.org/marketplace/distros/>`__.
 
-Can I use DevStack as a development environment?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Sure, you can. That said, there are a couple of things you should note before
-doing so:
-
-- DevStack makes a lot of configuration changes to your system and should not
-  be run in your main development environment.
-
-- All the repositories that DevStack clones when deploying are considered
-  volatile by default and thus are subject to hard resets. This is necessary to
-  keep you in sync with the latest upstream, which is what you want in a CI
-  situation, but it can result in branches being overwritten and files being
-  removed.
-
-  The corollary of this is that if you are working on a specific project, using
-  the DevStack project repository (defaulted to ``/opt/stack/<project>``) as
-  the single master repository for storing all your work is not recommended.
-  This behavior can be overridden by setting the ``RECLONE`` config option to
-  ``no``.  Alternatively, you can avoid running ``stack.sh`` to redeploy by
-  restarting services manually. In any case, you should generally ensure work
-  in progress is pushed to Gerrit or otherwise backed up before running
-  ``stack.sh``.
-
-- If you use DevStack within a VM, you may wish to mount a local OpenStack
-  directory, such as ``~/src/openstack``, inside the VM and configure DevStack
-  to use this as the clone location using the ``{PROJECT}_REPO`` config
-  variables. For example, assuming you're using Vagrant and sharing your home
-  directory, you should place the following in ``local.conf``:
-
-  .. code-block:: shell
-
-     NEUTRON_REPO=/home/vagrant/src/neutron
-     NOVA_REPO=/home/vagrant/src/nova
-     KEYSTONE_REPO=/home/vagrant/src/keystone
-     GLANCE_REPO=/home/vagrant/src/glance
-     SWIFT_REPO=/home/vagrant/src/swift
-     HORIZON_REPO=/home/vagrant/src/horizon
-     CINDER_REPO=/home/vagrant/src/cinder
-     HEAT_REPO=/home/vagrant/src/heat
-     TEMPEST_REPO=/home/vagrant/src/tempest
-     HEATCLIENT_REPO=/home/vagrant/src/python-heatclient
-     GLANCECLIENT_REPO=/home/vagrant/src/python-glanceclient
-     NOVACLIENT_REPO=/home/vagrant/src/python-novaclient
-     NEUTRONCLIENT_REPO=/home/vagrant/src/python-neutronclient
-     OPENSTACKCLIENT_REPO=/home/vagrant/src/python-openstackclient
-     HEAT_CFNTOOLS_REPO=/home/vagrant/src/heat-cfntools
-     HEAT_TEMPLATES_REPO=/home/vagrant/src/heat-templates
-     NEUTRON_FWAAS_REPO=/home/vagrant/src/neutron-fwaas
-     # ...
-
 Why a shell script, why not chef/puppet/...
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -80,20 +29,20 @@ I'd like to help!
 ~~~~~~~~~~~~~~~~~
 
 That isn't a question, but please do! The source for DevStack is at
-`opendev.org <https://opendev.org/openstack/devstack>`__ and bug
+`git.openstack.org
+<https://git.openstack.org/cgit/openstack-dev/devstack>`__ and bug
 reports go to `LaunchPad
-<https://bugs.launchpad.net/devstack/>`__. Contributions follow the
+<http://bugs.launchpad.net/devstack/>`__. Contributions follow the
 usual process as described in the `developer guide
-<https://docs.openstack.org/infra/manual/developers.html>`__. This
+<http://docs.openstack.org/infra/manual/developers.html>`__. This
 Sphinx documentation is housed in the doc directory.
 
 Why not use packages?
 ~~~~~~~~~~~~~~~~~~~~~
 
 Unlike packages, DevStack leaves your cloud ready to develop -
-checkouts of the code and services running locally under systemd,
-making it easy to hack on and test new patches. However, many people
-are doing the hard work of packaging and recipes for production
+checkouts of the code and services running in screen. However, many
+people are doing the hard work of packaging and recipes for production
 deployments.
 
 Why isn't $MY\_FAVORITE\_DISTRO supported?
@@ -105,7 +54,7 @@ combinations listed in ``README.md``. DevStack is only supported on
 releases other than those documented in ``README.md`` on a best-effort
 basis.
 
-Are there any differences between Ubuntu and CentOS/Fedora support?
+Are there any differences between Ubuntu and Centos/Fedora support?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Both should work well and are tested by DevStack CI.
@@ -136,7 +85,7 @@ through bash for this
 
    function sourceopenrc {
        pushd ~/devstack >/dev/null
-       eval $(bash -c ". openrc $1 $2 >/dev/null;env|sed -n '/OS_/ { s/^/export /;p}'")
+       eval $(bash -c ". openrc $1 $2;env|sed -n '/OS_/ { s/^/export /;p}'")
        popd >/dev/null
    }
 
@@ -161,11 +110,11 @@ How do I turn off a service that is enabled by default?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Services can be turned off by adding ``disable_service xxx`` to
-``local.conf`` (using ``c-vol`` in this example):
+``local.conf`` (using ``n-vol`` in this example):
 
     ::
 
-        disable_service c-vol
+        disable_service n-vol
 
 Is enabling a service that defaults to off done with the reverse of the above?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -175,30 +124,24 @@ Of course!
 
         enable_service q-svc
 
-How do I run a specific OpenStack release?
+How do I run a specific OpenStack milestone?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-DevStack master tracks the upstream master of all the projects. If you
-would like to run a stable branch of OpenStack, you should use the
-corresponding stable branch of DevStack as well. For instance the
-``stable/ocata`` version of DevStack will already default to all the
-projects running at ``stable/ocata`` levels.
+OpenStack milestones have tags set in the git repo. Set the
+appropriate tag in the ``*_BRANCH`` variables in ``local.conf``.
+Swift is on its own release schedule so pick a tag in the Swift repo
+that is just before the milestone release. For example:
 
-Note: it's also possible to manually adjust the ``*_BRANCH`` variables
-further if you would like to test specific milestones, or even custom
-out of tree branches. This is done with entries like the following in
-your ``local.conf``
-
-::
+    ::
 
         [[local|localrc]]
-        GLANCE_BRANCH=11.0.0.0rc1
-        NOVA_BRANCH=12.0.0.0.rc1
-
-
-Upstream DevStack is only tested with master and stable
-branches. Setting custom BRANCH definitions is not guaranteed to
-produce working results.
+        GLANCE_BRANCH=stable/kilo
+        HORIZON_BRANCH=stable/kilo
+        KEYSTONE_BRANCH=stable/kilo
+        NOVA_BRANCH=stable/kilo
+        GLANCE_BRANCH=stable/kilo
+        NEUTRON_BRANCH=stable/kilo
+        SWIFT_BRANCH=2.3.0
 
 What can I do about RabbitMQ not wanting to start on my fresh new VM?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -209,6 +152,16 @@ to a working IP address; setting it to 127.0.0.1 in ``/etc/hosts`` is
 often good enough for a single-node installation. And in an extreme
 case, use ``clean.sh`` to eradicate it and try again.
 
+Configure ``local.conf`` thusly:
+
+    ::
+
+        [[local|localrc]]
+        HEAT_STANDALONE=True
+        ENABLED_SERVICES=rabbit,mysql,heat,h-api,h-api-cfn,h-api-cw,h-eng
+        KEYSTONE_SERVICE_HOST=<keystone-host>
+        KEYSTONE_AUTH_HOST=<keystone-host>
+
 Why are my configuration changes ignored?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 

doc/source/guides.rst

@@ -1,80 +0,0 @@
-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:
-   :hidden:
-   :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-octavia
-   guides/devstack-with-ldap
-
-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>`.
-
-Configure Octavia
------------------
-
-Guide on :doc:`Configure Octavia <guides/devstack-with-octavia>`.
-
-Deploying DevStack with LDAP
-----------------------------
-
-Guide to setting up :doc:`DevStack with LDAP <guides/devstack-with-ldap>`.

doc/source/guides/devstack-with-lbaas-v2.rst

@@ -0,0 +1,99 @@
+Configure Load-Balancer in Kilo
+=================================
+
+The Kilo release of OpenStack will support Version 2 of the neutron load balancer. Until now, using OpenStack `LBaaS V2 <http://docs.openstack.org/api/openstack-network/2.0/content/lbaas_ext.html>`_ has required a good understanding of neutron and LBaaS architecture and several manual steps.
+
+
+Phase 1: Create DevStack + 2 nova instances
+--------------------------------------------
+
+First, set up a vm of your choice with at least 8 GB RAM and 16 GB disk space, make sure it is updated. Install git and any other developer tools you find useful.
+
+Install devstack
+
+  ::
+
+    git clone https://git.openstack.org/openstack-dev/devstack
+    cd devstack
+
+
+Edit your `local.conf` to look like
+
+  ::
+
+    [[local|localrc]]
+    # Load the external LBaaS plugin.
+    enable_plugin neutron-lbaas https://git.openstack.org/openstack/neutron-lbaas
+
+    # ===== BEGIN localrc =====
+    DATABASE_PASSWORD=password
+    ADMIN_PASSWORD=password
+    SERVICE_PASSWORD=password
+    SERVICE_TOKEN=password
+    RABBIT_PASSWORD=password
+    # Enable Logging
+    LOGFILE=$DEST/logs/stack.sh.log
+    VERBOSE=True
+    LOG_COLOR=True
+    SCREEN_LOGDIR=$DEST/logs
+    # Pre-requisite
+    ENABLED_SERVICES=rabbit,mysql,key
+    # Horizon
+    ENABLED_SERVICES+=,horizon
+    # Nova
+    ENABLED_SERVICES+=,n-api,n-crt,n-obj,n-cpu,n-cond,n-sch
+    IMAGE_URLS+=",https://launchpad.net/cirros/trunk/0.3.0/+download/cirros-0.3.0-x86_64-disk.img"
+    # Glance
+    ENABLED_SERVICES+=,g-api,g-reg
+    # Neutron
+    ENABLED_SERVICES+=,q-svc,q-agt,q-dhcp,q-l3,q-meta
+    # Enable LBaaS V2
+    ENABLED_SERVICES+=,q-lbaasv2
+    # Cinder
+    ENABLED_SERVICES+=,c-api,c-vol,c-sch
+    # Tempest
+    ENABLED_SERVICES+=,tempest
+    # ===== END localrc =====
+
+Run stack.sh and do some sanity checks
+
+  ::
+
+    ./stack.sh
+    . ./openrc
+
+    neutron net-list  # should show public and private networks
+
+Create two nova instances that we can use as test http servers:
+
+  ::
+
+    #create nova instances on private network
+    nova boot --image $(nova image-list | awk '/ cirros-0.3.0-x86_64-disk / {print $2}') --flavor 1 --nic net-id=$(neutron net-list | awk '/ private / {print $2}') node1
+    nova boot --image $(nova image-list | awk '/ cirros-0.3.0-x86_64-disk / {print $2}') --flavor 1 --nic net-id=$(neutron net-list | awk '/ private / {print $2}') node2
+    nova list # should show the nova instances just created
+
+    #add secgroup rule to allow ssh etc..
+    neutron security-group-rule-create default --protocol icmp
+    neutron security-group-rule-create default --protocol tcp --port-range-min 22 --port-range-max 22
+    neutron security-group-rule-create default --protocol tcp --port-range-min 80 --port-range-max 80
+
+Set up a simple web server on each of these instances. ssh into each instance (username 'cirros', password 'cubswin:)') and run
+
+ ::
+
+    MYIP=$(ifconfig eth0|grep 'inet addr'|awk -F: '{print $2}'| awk '{print $1}')
+    while true; do echo -e "HTTP/1.0 200 OK\r\n\r\nWelcome to $MYIP" | sudo nc -l -p 80 ; done&
+
+Phase 2: Create your load balancers
+------------------------------------
+
+ ::
+
+    neutron lbaas-loadbalancer-create --name lb1 private-subnet
+    neutron lbaas-listener-create --loadbalancer lb1 --protocol HTTP --protocol-port 80 --name listener1
+    neutron lbaas-pool-create --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP --name pool1
+    neutron lbaas-member-create  --subnet private-subnet --address 10.0.0.3 --protocol-port 80 pool1
+    neutron lbaas-member-create  --subnet private-subnet --address 10.0.0.5 --protocol-port 80 pool1
+
+Please note here that the "10.0.0.3" and "10.0.0.5" in the above commands are the IPs of the nodes (in my test run-thru, they were actually 10.2 and 10.4), and the address of the created LB will be reported as "vip_address" from the lbaas-loadbalancer-create, and a quick test of that LB is "curl that-lb-ip", which should alternate between showing the IPs of the two nodes.

doc/source/guides/devstack-with-ldap.rst

@@ -1,174 +0,0 @@
-============================
-Deploying DevStack with LDAP
-============================
-
-The OpenStack Identity service has the ability to integrate with LDAP. The goal
-of this guide is to walk you through setting up an LDAP-backed OpenStack
-development environment.
-
-Introduction
-============
-
-LDAP support in keystone is read-only. You can use it to back an entire
-OpenStack deployment to a single LDAP server, or you can use it to back
-separate LDAP servers to specific keystone domains. Users within those domains
-can authenticate against keystone, assume role assignments, and interact with
-other OpenStack services.
-
-Configuration
-=============
-
-To deploy an OpenLDAP server, make sure ``ldap`` is added to the list of
-``ENABLED_SERVICES`` in the ``local.conf`` file::
-
-    enable_service ldap
-
-Devstack will require a password to set up an LDAP administrator. This
-administrative user is also the bind user specified in keystone's configuration
-files, similar to a ``keystone`` user for MySQL databases.
-
-Devstack will prompt you for a password when running ``stack.sh`` if
-``LDAP_PASSWORD`` is not set. You can add the following to your
-``local.conf``::
-
-    LDAP_PASSWORD=super_secret_password
-
-At this point, devstack should have everything it needs to deploy OpenLDAP,
-bootstrap it with a minimal set of users, and configure it to back to a domain
-in keystone. You can do this by running the ``stack.sh`` script::
-
-    $ ./stack.sh
-
-Once ``stack.sh`` completes, you should have a running keystone deployment with
-a basic set of users. It is important to note that not all users will live
-within LDAP. Instead, keystone will back different domains to different
-identity sources. For example, the ``default`` domain will be backed by MySQL.
-This is usually where you'll find your administrative and services users. If
-you query keystone for a list of domains, you should see a domain called
-``Users``. This domain is set up by devstack and points to OpenLDAP.
-
-User Management
-===============
-
-Initially, there will only be two users in the LDAP server. The ``Manager``
-user is used by keystone to talk to OpenLDAP. The ``demo`` user is a generic
-user that you should be able to see if you query keystone for users within the
-``Users`` domain. Both of these users were added to LDAP using basic LDAP
-utilities installed by devstack (e.g. ``ldap-utils``) and LDIFs. The LDIFs used
-to create these users can be found in ``devstack/files/ldap/``.
-
-Listing Users
--------------
-
-To list all users in LDAP directly, you can use ``ldapsearch`` with the LDAP
-user bootstrapped by devstack::
-
-    $ ldapsearch -x -w LDAP_PASSWORD -D cn=Manager,dc=openstack,dc=org \
-        -H ldap://localhost -b dc=openstack,dc=org
-
-As you can see, devstack creates an OpenStack domain called ``openstack.org``
-as a container for the ``Manager`` and ``demo`` users.
-
-Creating Users
---------------
-
-Since keystone's LDAP integration is read-only, users must be added directly to
-LDAP. Users added directly to OpenLDAP will automatically be placed into the
-``Users`` domain.
-
-LDIFs can be used to add users via the command line. The following is an
-example LDIF that can be used to create a new LDAP user, let's call it
-``peter.ldif.in``::
-
-    dn: cn=peter,ou=Users,dc=openstack,dc=org
-    cn: peter
-    displayName: Peter Quill
-    givenName: Peter Quill
-    mail: starlord@openstack.org
-    objectClass: inetOrgPerson
-    objectClass: top
-    sn: peter
-    uid: peter
-    userPassword: im-a-better-pilot-than-rocket
-
-Now, we use the ``Manager`` user to create a user for Peter in LDAP::
-
-    $ ldapadd -x -w LDAP_PASSWORD -D cn=Manager,dc=openstack,dc=org \
-        -H ldap://localhost -c -f peter.ldif.in
-
-We should be able to assign Peter roles on projects. After Peter has some level
-of authorization, he should be able to login to Horizon by specifying the
-``Users`` domain and using his ``peter`` username and password. Authorization
-can be given to Peter by creating a project within the ``Users`` domain and
-giving him a role assignment on that project::
-
-    $ openstack project create --domain Users awesome-mix-vol-1
-    +-------------+----------------------------------+
-    | Field       | Value                            |
-    +-------------+----------------------------------+
-    | description |                                  |
-    | domain_id   | 61a2de23107c46bea2d758167af707b9 |
-    | enabled     | True                             |
-    | id          | 7d422396d54945cdac8fe1e8e32baec4 |
-    | is_domain   | False                            |
-    | name        | awesome-mix-vol-1                |
-    | parent_id   | 61a2de23107c46bea2d758167af707b9 |
-    | tags        | []                               |
-    +-------------+----------------------------------+
-    $ openstack role add --user peter --user-domain Users \
-          --project awesome-mix-vol-1 --project-domain Users admin
-
-
-Deleting Users
---------------
-
-We can use the same basic steps to remove users from LDAP, but instead of using
-LDIFs, we can just pass the ``dn`` of the user we want to delete::
-
-    $ ldapdelete -x -w LDAP_PASSWORD -D cn=Manager,dc=openstack,dc=org \
-        -H ldap://localhost cn=peter,ou=Users,dc=openstack,dc=org
-
-Group Management
-================
-
-Like users, groups are considered specific identities. This means that groups
-also fall under the same read-only constraints as users and they can be managed
-directly with LDAP in the same way users are with LDIFs.
-
-Adding Groups
--------------
-
-Let's define a specific group with the following LDIF::
-
-    dn: cn=guardians,ou=UserGroups,dc=openstack,dc=org
-    objectClass: groupOfNames
-    cn: guardians
-    description: Guardians of the Galaxy
-    member: cn=peter,dc=openstack,dc=org
-    member: cn=gamora,dc=openstack,dc=org
-    member: cn=drax,dc=openstack,dc=org
-    member: cn=rocket,dc=openstack,dc=org
-    member: cn=groot,dc=openstack,dc=org
-
-We can create the group using the same ``ldapadd`` command as we did with
-users::
-
-    $ ldapadd -x -w LDAP_PASSWORD -D cn=Manager,dc=openstack,dc=org \
-        -H ldap://localhost -c -f guardian-group.ldif.in
-
-If we check the group membership in Horizon, we'll see that only Peter is a
-member of the ``guardians`` group, despite the whole crew being specified in
-the LDIF. Once those accounts are created in LDAP, they will automatically be
-added to the ``guardians`` group. They will also assume any role assignments
-given to the ``guardians`` group.
-
-Deleting Groups
----------------
-
-Just like users, groups can be deleted using the ``dn``::
-
-    $ ldapdelete -x -w LDAP_PASSWORD -D cn=Manager,dc=openstack,dc=org \
-        -H ldap://localhost cn=guardians,ou=UserGroups,dc=openstack,dc=org
-
-Note that this operation will not remove users within that group. It will only
-remove the group itself and the memberships any users had with that group.

doc/source/guides/devstack-with-nested-kvm.rst

@@ -1,5 +1,3 @@
-.. _kvm_nested_virt:
-
 =======================================================
 Configure DevStack with KVM-based Nested Virtualization
 =======================================================
@@ -52,7 +50,7 @@ the host:
     parm:           nested:bool
 
 Start your VM, now it should have KVM capabilities -- you can verify
-that by ensuring ``/dev/kvm`` character device is present.
+that by ensuring `/dev/kvm` character device is present.
 
 
 Configure Nested KVM for AMD-based Machines
@@ -75,7 +73,7 @@ back:
 ::
 
     sudo rmmod kvm-amd
-    sudo sh -c "echo 'options kvm-amd nested=1' >> /etc/modprobe.d/dist.conf"
+    sudo sh -c "echo 'options amd nested=1' >> /etc/modprobe.d/dist.conf"
     sudo modprobe kvm-amd
 
 Ensure the Nested KVM Kernel module parameter for AMD is enabled on the
@@ -99,7 +97,7 @@ To make the above value persistent across reboots, add an entry in
 Expose Virtualization Extensions to DevStack VM
 -----------------------------------------------
 
-Edit the VM's libvirt XML configuration via ``virsh`` utility:
+Edit the VM's libvirt XML configuration via `virsh` utility:
 
 ::
 
@@ -117,10 +115,10 @@ Ensure DevStack VM is Using KVM
 -------------------------------
 
 Before invoking ``stack.sh`` in the VM, ensure that KVM is enabled. This
-can be verified by checking for the presence of the file ``/dev/kvm`` in
+can be verified by checking for the presence of the file `/dev/kvm` in
 your VM. If it is present, DevStack will default to using the config
-attribute ``virt_type = kvm`` in ``/etc/nova.conf``; otherwise, it'll fall
-back to ``virt_type=qemu``, i.e. plain QEMU emulation.
+attribute `virt_type = kvm` in `/etc/nova.conf`; otherwise, it'll fall
+back to `virt_type=qemu`, i.e. plain QEMU emulation.
 
 Optionally, to explicitly set the type of virtualization, to KVM, by the
 libvirt driver in nova, the below config attribute can be used in
@@ -133,7 +131,7 @@ DevStack's ``local.conf``:
 
 Once DevStack is configured successfully, verify if the Nova instances
 are using KVM by noticing the QEMU CLI invoked by Nova is using the
-parameter ``accel=kvm``, e.g.:
+parameter `accel=kvm`, e.g.:
 
 ::
 

doc/source/guides/devstack-with-octavia.rst

@@ -1,144 +0,0 @@
-Devstack with Octavia Load Balancing
-====================================
-
-Starting with the OpenStack Pike release, Octavia is now a standalone service
-providing load balancing services for OpenStack.
-
-This guide will show you how to create a devstack with `Octavia API`_ enabled.
-
-.. _Octavia API: https://docs.openstack.org/api-ref/load-balancer/v2/index.html
-
-Phase 1: Create DevStack + 2 nova instances
---------------------------------------------
-
-First, set up a VM of your choice with at least 8 GB RAM and 16 GB disk space,
-make sure it is updated. Install git and any other developer tools you find
-useful.
-
-Install devstack::
-
-    git clone https://opendev.org/openstack/devstack
-    cd devstack/tools
-    sudo ./create-stack-user.sh
-    cd ../..
-    sudo mv devstack /opt/stack
-    sudo chown -R stack.stack /opt/stack/devstack
-
-This will clone the current devstack code locally, then setup the "stack"
-account that devstack services will run under. Finally, it will move devstack
-into its default location in /opt/stack/devstack.
-
-Edit your ``/opt/stack/devstack/local.conf`` to look like::
-
-    [[local|localrc]]
-    # ===== BEGIN localrc =====
-    DATABASE_PASSWORD=password
-    ADMIN_PASSWORD=password
-    SERVICE_PASSWORD=password
-    SERVICE_TOKEN=password
-    RABBIT_PASSWORD=password
-    GIT_BASE=https://opendev.org
-    # Optional settings:
-    # OCTAVIA_AMP_BASE_OS=centos
-    # OCTAVIA_AMP_DISTRIBUTION_RELEASE_ID=9-stream
-    # OCTAVIA_AMP_IMAGE_SIZE=3
-    # OCTAVIA_LB_TOPOLOGY=ACTIVE_STANDBY
-    # OCTAVIA_ENABLE_AMPHORAV2_JOBBOARD=True
-    # LIBS_FROM_GIT+=octavia-lib,
-    # Enable Logging
-    LOGFILE=$DEST/logs/stack.sh.log
-    VERBOSE=True
-    LOG_COLOR=True
-    enable_service rabbit
-    enable_plugin neutron $GIT_BASE/openstack/neutron
-    # Octavia supports using QoS policies on the VIP port:
-    enable_service q-qos
-    enable_service placement-api placement-client
-    # Octavia services
-    enable_plugin octavia $GIT_BASE/openstack/octavia master
-    enable_plugin octavia-dashboard $GIT_BASE/openstack/octavia-dashboard
-    enable_plugin ovn-octavia-provider $GIT_BASE/openstack/ovn-octavia-provider
-    enable_plugin octavia-tempest-plugin $GIT_BASE/openstack/octavia-tempest-plugin
-    enable_service octavia o-api o-cw o-hm o-hk o-da
-    # If you are enabling barbican for TLS offload in Octavia, include it here.
-    # enable_plugin barbican $GIT_BASE/openstack/barbican
-    # enable_service barbican
-    # Cinder (optional)
-    disable_service c-api c-vol c-sch
-    # Tempest
-    enable_service tempest
-    # ===== END localrc =====
-
-.. note::
-    For best performance it is highly recommended to use KVM
-    virtualization instead of QEMU.
-    Also make sure nested virtualization is enabled as documented in
-    :ref:`the respective guide <kvm_nested_virt>`.
-    By adding ``LIBVIRT_CPU_MODE="host-passthrough"`` to your
-    ``local.conf`` you enable the guest VMs to make use of all features your
-    host's CPU provides.
-
-Run stack.sh and do some sanity checks::
-
-    sudo su - stack
-    cd /opt/stack/devstack
-    ./stack.sh
-    . ./openrc
-
-    openstack network list  # should show public and private networks
-
-Create two nova instances that we can use as test http servers::
-
-    # create nova instances on private network
-    openstack server create --image $(openstack image list | awk '/ cirros-.*-x86_64-.* / {print $2}') --flavor 1 --nic net-id=$(openstack network list | awk '/ private / {print $2}') node1
-    openstack server create --image $(openstack image list | awk '/ cirros-.*-x86_64-.* / {print $2}') --flavor 1 --nic net-id=$(openstack network list | awk '/ private / {print $2}') node2
-    openstack server list # should show the nova instances just created
-
-    # add secgroup rules to allow ssh etc..
-    openstack security group rule create default --protocol icmp
-    openstack security group rule create default --protocol tcp --dst-port 22:22
-    openstack security group rule create default --protocol tcp --dst-port 80:80
-
-Set up a simple web server on each of these instances. One possibility is to use
-the `Golang test server`_ that is used by the Octavia project for CI testing
-as well.
-Copy the binary to your instances and start it as shown below
-(username 'cirros', password 'gocubsgo')::
-
-    INST_IP=<instance IP>
-    scp -O test_server.bin cirros@${INST_IP}:
-    ssh -f cirros@${INST_IP} ./test_server.bin -id ${INST_IP}
-
-When started this way the test server will respond to HTTP requests with
-its own IP.
-
-Phase 2: Create your load balancer
-----------------------------------
-
-Create your load balancer::
-
-    openstack loadbalancer create --wait --name lb1 --vip-subnet-id private-subnet
-    openstack loadbalancer listener create --wait --protocol HTTP --protocol-port 80 --name listener1 lb1
-    openstack loadbalancer pool create --wait --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP --name pool1
-    openstack loadbalancer healthmonitor create --wait --delay 5 --timeout 2 --max-retries 1 --type HTTP pool1
-    openstack loadbalancer member create --wait --subnet-id private-subnet --address <web server 1 address> --protocol-port 80 pool1
-    openstack loadbalancer member create --wait --subnet-id private-subnet --address <web server 2 address> --protocol-port 80 pool1
-
-Please note: The <web server # address> fields are the IP addresses of the nova
-servers created in Phase 1.
-Also note, using the API directly you can do all of the above commands in one
-API call.
-
-Phase 3: Test your load balancer
---------------------------------
-
-::
-
-    openstack loadbalancer show lb1 # Note the vip_address
-    curl http://<vip_address>
-    curl http://<vip_address>
-
-This should show the "Welcome to <IP>" message from each member server.
-
-
-.. _Golang test server: https://opendev.org/openstack/octavia-tempest-plugin/src/branch/master/octavia_tempest_plugin/contrib/test_server

doc/source/guides/lxc.rst

@@ -1,164 +0,0 @@
-================================
-All-In-One Single LXC Container
-================================
-
-This guide walks you through the process of deploying OpenStack using devstack
-in an LXC container instead of a VM.
-
-The primary benefits to running devstack inside a container instead of a VM is
-faster performance and lower memory overhead while still providing a suitable
-level of isolation. This can be particularly useful when you want to simulate
-running OpenStack on multiple nodes.
-
-.. Warning:: Containers do not provide the same level of isolation as a virtual
-   machine.
-
-.. Note:: Not all OpenStack features support running inside of a container. See
-   `Limitations`_ section below for details. :doc:`OpenStack in a VM <single-vm>`
-   is recommended for beginners.
-
-Prerequisites
-==============
-
-This guide is written for Ubuntu 14.04 but should be adaptable for any modern
-Linux distribution.
-
-Install the LXC package::
-
-   sudo apt-get install lxc
-
-You can verify support for containerization features in your currently running
-kernel using the ``lxc-checkconfig`` command.
-
-Container Setup
-===============
-
-Configuration
----------------
-
-For a successful run of ``stack.sh`` and to permit use of KVM to run the VMs you
-launch inside your container, we need to use the following additional
-configuration options. Place the following in a file called
-``devstack-lxc.conf``::
-
-  # Permit access to /dev/loop*
-  lxc.cgroup.devices.allow = b 7:* rwm
-  
-  # Setup access to /dev/net/tun and /dev/kvm
-  lxc.mount.entry = /dev/net/tun dev/net/tun none bind,create=file 0 0
-  lxc.mount.entry = /dev/kvm dev/kvm none bind,create=file 0 0
-  
-  # Networking
-  lxc.network.type = veth
-  lxc.network.flags = up
-  lxc.network.link = lxcbr0
-
-
-Create Container
--------------------
-
-The configuration and rootfs for LXC containers are created using the
-``lxc-create`` command.
-
-We will name our container ``devstack`` and use the ``ubuntu`` template which
-will use ``debootstrap`` to build a Ubuntu rootfs. It will default to the same
-release and architecture as the host system. We also install the additional
-packages ``bsdmainutils`` and ``git`` as we'll need them to run devstack::
-
-  sudo lxc-create -n devstack -t ubuntu -f devstack-lxc.conf -- --packages=bsdmainutils,git
-
-The first time it builds the rootfs will take a few minutes to download, unpack,
-and configure all the necessary packages for a minimal installation of Ubuntu.
-LXC will cache this and subsequent containers will only take seconds to create.
-
-.. Note:: To speed up the initial rootfs creation, you can specify a mirror to
-   download the Ubuntu packages from by appending ``--mirror=`` and then the URL
-   of a Ubuntu mirror. To see other other template options, you can run
-   ``lxc-create -t ubuntu -h``.
-
-Start Container
-----------------
-
-To start the container, run::
-
-  sudo lxc-start -n devstack
-
-A moment later you should be presented with the login prompt for your container.
-You can login using the username ``ubuntu`` and password ``ubuntu``.
-
-You can also ssh into your container. On your host, run
-``sudo lxc-info -n devstack`` to get the IP address (e.g. 
-``ssh ubuntu@$(sudo lxc-info -n devstack | awk '/IP/ { print $2 }')``).
-
-Run Devstack
--------------
-
-You should now be logged into your container and almost ready to run devstack.
-The commands in this section should all be run inside your container.
-
-.. Tip:: You can greatly reduce the runtime of your initial devstack setup by
-   ensuring you have your apt sources.list configured to use a fast mirror.
-   Check and update ``/etc/apt/sources.list`` if necessary and then run 
-   ``apt-get update``.
-
-#. Download DevStack
-
-   ::
-
-       git clone https://opendev.org/openstack/devstack
-
-#. Configure
-
-   Refer to :ref:`minimal-configuration` if you wish to configure the behaviour
-   of devstack.
-
-#. Start the install
-
-   ::
-
-       cd devstack
-       ./stack.sh
-
-Cleanup
--------
-
-To stop the container::
-
-  lxc-stop -n devstack
-
-To delete the container::
-
-  lxc-destroy -n devstack
-
-Limitations
-============
-
-Not all OpenStack features may function correctly or at all when ran from within
-a container.
-
-Cinder
--------
-
-Unable to create LVM backed volume
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-  In our configuration, we have not whitelisted access to device-mapper or LVM
-  devices. Doing so will permit your container to have access and control of LVM
-  on the host system. To enable, add the following to your
-  ``devstack-lxc.conf`` before running ``lxc-create``::
-
-    lxc.cgroup.devices.allow = c 10:236 rwm
-    lxc.cgroup.devices.allow = b 252:* rwm
-
-  Additionally you'll need to set ``udev_rules = 0`` in the ``activation``
-  section of ``/etc/lvm/lvm.conf`` unless you mount devtmpfs in your container.
-
-Unable to attach volume to instance
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-  It is not possible to attach cinder volumes to nova instances due to parts of
-  the Linux iSCSI implementation not being network namespace aware. This can be
-  worked around by using network pass-through instead of a separate network
-  namespace but such a setup significantly reduces the isolation of the
-  container (e.g. a ``halt`` command issued in the container will cause the host
-  system to shutdown).

doc/source/guides/multinode-lab.rst

@@ -73,15 +73,8 @@ Otherwise create the stack user:
 
 ::
 
-    useradd -s /bin/bash -d /opt/stack -m stack
-
-Ensure home directory for the ``stack`` user has executable permission for all,
-as RHEL based distros create it with ``700`` and Ubuntu 21.04+ with ``750``
-which can cause issues during deployment.
-
-::
-
-    chmod +x /opt/stack
+    groupadd stack
+    useradd -g stack -s /bin/bash -d /opt/stack -m stack
 
 This user will be making many changes to your system during installation
 and operation so it needs to have sudo privileges to root without a
@@ -89,7 +82,7 @@ password:
 
 ::
 
-    echo "stack ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/stack
+    echo "stack ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers
 
 From here on use the ``stack`` user. **Logout** and **login** as the
 ``stack`` user.
@@ -111,7 +104,7 @@ Grab the latest version of DevStack:
 
 ::
 
-    git clone https://opendev.org/openstack/devstack
+    git clone https://git.openstack.org/openstack-dev/devstack
     cd devstack
 
 Up to this point all of the steps apply to each node in the cluster.
@@ -128,13 +121,17 @@ cluster controller's DevStack in ``local.conf``:
 
     [[local|localrc]]
     HOST_IP=192.168.42.11
+    FLAT_INTERFACE=eth0
     FIXED_RANGE=10.4.128.0/20
+    FIXED_NETWORK_SIZE=4096
     FLOATING_RANGE=192.168.42.128/25
+    MULTI_HOST=1
     LOGFILE=/opt/stack/logs/stack.sh.log
     ADMIN_PASSWORD=labstack
-    DATABASE_PASSWORD=supersecret
-    RABBIT_PASSWORD=supersecret
-    SERVICE_PASSWORD=supersecret
+    MYSQL_PASSWORD=supersecret
+    RABBIT_PASSWORD=supersecrete
+    SERVICE_PASSWORD=supersecrete
+    SERVICE_TOKEN=xyzpdqlazydog
 
 In the multi-node configuration the first 10 or so IPs in the private
 subnet are usually reserved. Add this to ``local.sh`` to have it run
@@ -165,24 +162,33 @@ machines, create a ``local.conf`` with:
 
     [[local|localrc]]
     HOST_IP=192.168.42.12 # change this per compute node
+    FLAT_INTERFACE=eth0
     FIXED_RANGE=10.4.128.0/20
+    FIXED_NETWORK_SIZE=4096
     FLOATING_RANGE=192.168.42.128/25
+    MULTI_HOST=1
     LOGFILE=/opt/stack/logs/stack.sh.log
     ADMIN_PASSWORD=labstack
-    DATABASE_PASSWORD=supersecret
-    RABBIT_PASSWORD=supersecret
-    SERVICE_PASSWORD=supersecret
+    MYSQL_PASSWORD=supersecret
+    RABBIT_PASSWORD=supersecrete
+    SERVICE_PASSWORD=supersecrete
+    SERVICE_TOKEN=xyzpdqlazydog
     DATABASE_TYPE=mysql
     SERVICE_HOST=192.168.42.11
     MYSQL_HOST=$SERVICE_HOST
     RABBIT_HOST=$SERVICE_HOST
     GLANCE_HOSTPORT=$SERVICE_HOST:9292
-    ENABLED_SERVICES=n-cpu,c-vol,placement-client,ovn-controller,ovs-vswitchd,ovsdb-server,q-ovn-metadata-agent
+    ENABLED_SERVICES=n-cpu,n-net,n-api-meta,c-vol
     NOVA_VNC_ENABLED=True
-    NOVNCPROXY_URL="http://$SERVICE_HOST:6080/vnc_lite.html"
+    NOVNCPROXY_URL="http://$SERVICE_HOST:6080/vnc_auto.html"
     VNCSERVER_LISTEN=$HOST_IP
     VNCSERVER_PROXYCLIENT_ADDRESS=$VNCSERVER_LISTEN
 
+**Note:** the ``n-api-meta`` service is a version of the api server
+that only serves the metadata service. It's needed because the
+computes created won't have a routing path to the metadata service on
+the controller.
+
 Fire up OpenStack:
 
 ::
@@ -194,22 +200,6 @@ A stream of activity ensues. When complete you will see a summary of
 to poke at your shiny new OpenStack. The most recent log file is
 available in ``stack.sh.log``.
 
-Starting in the Ocata release, Nova requires a `Cells v2`_ deployment. Compute
-node services must be mapped to a cell before they can be used.
-
-After each compute node is stacked, verify it shows up in the
-``nova service-list --binary nova-compute`` output. The compute service is
-registered in the cell database asynchronously so this may require polling.
-
-Once the compute node services shows up, run the ``./tools/discover_hosts.sh``
-script from the control node to map compute hosts to the single cell.
-
-The compute service running on the primary control node will be
-discovered automatically when the control node is stacked so this really
-only needs to be performed for subnodes.
-
-.. _Cells v2: https://docs.openstack.org/nova/latest/user/cells.html
-
 Cleaning Up After DevStack
 --------------------------
 
@@ -237,8 +227,8 @@ this when it runs but there are times it needs to still be done by hand:
     sudo rm -rf /etc/libvirt/qemu/inst*
     sudo virsh list | grep inst | awk '{print $1}' | xargs -n1 virsh destroy
 
-Going further
-=============
+Options pimp your stack
+=======================
 
 Additional Users
 ----------------
@@ -266,13 +256,13 @@ for scripting:
 
     # Add a user and project
     NAME=bob
-    PASSWORD=BigSecret
+    PASSWORD=BigSecrete
     PROJECT=$NAME
     openstack project create $PROJECT
     openstack user create $NAME --password=$PASSWORD --project $PROJECT
     openstack role add Member --user $NAME --project $PROJECT
     # The Member role is created by stack.sh
-    # openstack role assignment list
+    # openstack role list
 
 Swift
 -----
@@ -299,17 +289,17 @@ Volumes
 
 DevStack will automatically use an existing LVM volume group named
 ``stack-volumes`` to store cloud-created volumes. If ``stack-volumes``
-doesn't exist, DevStack will set up a loop-mounted file to contain
-it.  If the default size is insufficient for the number and size of volumes
-required, it can be overridden by setting ``VOLUME_BACKING_FILE_SIZE`` in
-``local.conf`` (sizes given in ``truncate`` compatible format, e.g. ``24G``).
+doesn't exist, DevStack will set up a 10Gb loop-mounted file to contain
+it. This obviously limits the number and size of volumes that can be
+created inside OpenStack. The size can be overridden by setting
+``VOLUME_BACKING_FILE_SIZE`` in ``local.conf``.
 
 ``stack-volumes`` can be pre-created on any physical volume supported by
 Linux's LVM. The name of the volume group can be changed by setting
-``VOLUME_GROUP_NAME`` in ``localrc``. ``stack.sh`` deletes all logical
-volumes in ``VOLUME_GROUP_NAME`` that begin with ``VOLUME_NAME_PREFIX`` as
+``VOLUME_GROUP`` in ``localrc``. ``stack.sh`` deletes all logical
+volumes in ``VOLUME_GROUP`` that begin with ``VOLUME_NAME_PREFIX`` as
 part of cleaning up from previous runs. It is recommended to not use the
-root volume group as ``VOLUME_GROUP_NAME``.
+root volume group as ``VOLUME_GROUP``.
 
 The details of creating the volume group depends on the server hardware
 involved but looks something like this:
@@ -366,6 +356,17 @@ To pull glance, OpenStack Image service, from an experimental fork:
 Notes stuff you might need to know
 ==================================
 
+Reset the Bridge
+----------------
+
+How to reset the bridge configuration:
+
+::
+
+    sudo brctl delif br100 eth0.926
+    sudo ip link set dev br100 down
+    sudo brctl delbr br100
+
 Set MySQL Password
 ------------------
 
@@ -374,47 +375,3 @@ If you forgot to set the root password you can do this:
 ::
 
     mysqladmin -u root -pnova password 'supersecret'
-
-Live Migration
---------------
-
-In order for live migration to work with the default live migration URI::
-
-    [libvirt]
-    live_migration_uri = qemu+ssh://stack@%s/system
-
-SSH keys need to be exchanged between each compute node:
-
-1. The SOURCE root user's public RSA key (likely in /root/.ssh/id_rsa.pub)
-   needs to be in the DESTINATION stack user's authorized_keys file
-   (~stack/.ssh/authorized_keys).  This can be accomplished by manually
-   copying the contents from the file on the SOURCE to the DESTINATION.  If
-   you have a password configured for the stack user, then you can use the
-   following command to accomplish the same thing::
-
-        ssh-copy-id -i /root/.ssh/id_rsa.pub stack@DESTINATION
-
-2. The DESTINATION host's public ECDSA key (/etc/ssh/ssh_host_ecdsa_key.pub)
-   needs to be in the SOURCE root user's known_hosts file
-   (/root/.ssh/known_hosts).  This can be accomplished by running the
-   following on the SOURCE machine (hostname must be used)::
-
-        ssh-keyscan -H DEST_HOSTNAME | sudo tee -a /root/.ssh/known_hosts
-
-3. Verify that login via ssh works without a password::
-
-        ssh -i /root/.ssh/id_rsa stack@DESTINATION
-
-In essence, this means that every compute node's root user's public RSA key
-must exist in every other compute node's stack user's authorized_keys file and
-every compute node's public ECDSA key needs to be in every other compute
-node's root user's known_hosts file.  Please note that if the root or stack
-user does not have a SSH key, one can be generated using::
-
-    ssh-keygen -t rsa
-
-The above steps are necessary because libvirtd runs as root when the
-live_migration_uri uses the "qemu:///system" family of URIs.  For more
-information, see the `libvirt documentation`_.
-
-.. _libvirt documentation: https://libvirt.org/drvqemu.html#securitydriver

doc/source/guides/neutron.rst

@@ -6,8 +6,6 @@ This guide will walk you through using OpenStack neutron with the ML2
 plugin and the Open vSwitch mechanism driver.
 
 
-.. _single-interface-ovs:
-
 Using Neutron with a Single Interface
 =====================================
 
@@ -15,20 +13,8 @@ In some instances, like on a developer laptop, there is only one
 network interface that is available. In this scenario, the physical
 interface is added to the Open vSwitch bridge, and the IP address of
 the laptop is migrated onto the bridge interface. That way, the
-physical interface can be used to transmit self service project
-network traffic, the OpenStack API traffic, and management traffic.
-
-
-.. warning::
-
-    When using a single interface networking setup, there will be a
-    temporary network outage as your IP address is moved from the
-    physical NIC of your machine, to the OVS bridge. If you are SSH'd
-    into the machine from another computer, there is a risk of being
-    disconnected from your ssh session (due to arp cache
-    invalidation), which would stop the stack.sh or leave it in an
-    unfinished state. In these cases, start stack.sh inside its own
-    screen session so it can continue to run.
+physical interface can be used to transmit tenant network traffic,
+the OpenStack API traffic, and management traffic.
 
 
 Physical Network Setup
@@ -37,223 +23,69 @@ Physical Network Setup
 In most cases where DevStack is being deployed with a single
 interface, there is a hardware router that is being used for external
 connectivity and DHCP. The developer machine is connected to this
-network and is on a shared subnet with other machines.  The
-`local.conf` exhibited here assumes that 1500 is a reasonable MTU to
-use on that network.
+network and is on a shared subnet with other machines.
 
-.. image:: /assets/images/neutron-network-1.png
-   :alt: Network configuration for a single DevStack node
+.. nwdiag::
+
+        nwdiag {
+                inet [ shape = cloud ];
+                router;
+                inet -- router;
+
+                network hardware_network {
+                        address = "172.18.161.0/24"
+                        router [ address = "172.18.161.1" ];
+                        devstack_laptop [ address = "172.18.161.6" ];
+                }
+        }
 
 
 DevStack Configuration
 ----------------------
 
-The following is a complete `local.conf` for the host named
-`devstack-1`. It will run all the API and services, as well as
-serving as a hypervisor for guest instances.
 
 ::
 
-        [[local|localrc]]
         HOST_IP=172.18.161.6
         SERVICE_HOST=172.18.161.6
         MYSQL_HOST=172.18.161.6
         RABBIT_HOST=172.18.161.6
         GLANCE_HOSTPORT=172.18.161.6:9292
-        ADMIN_PASSWORD=secret
-        DATABASE_PASSWORD=secret
-        RABBIT_PASSWORD=secret
-        SERVICE_PASSWORD=secret
+        ADMIN_PASSWORD=secrete
+        MYSQL_PASSWORD=secrete
+        RABBIT_PASSWORD=secrete
+        SERVICE_PASSWORD=secrete
+        SERVICE_TOKEN=secrete
 
         ## Neutron options
         Q_USE_SECGROUP=True
         FLOATING_RANGE="172.18.161.0/24"
-        IPV4_ADDRS_SAFE_TO_USE="10.0.0.0/22"
+        FIXED_RANGE="10.0.0.0/24"
         Q_FLOATING_ALLOCATION_POOL=start=172.18.161.250,end=172.18.161.254
         PUBLIC_NETWORK_GATEWAY="172.18.161.1"
+        Q_L3_ENABLED=True
         PUBLIC_INTERFACE=eth0
-
-        # Open vSwitch provider networking configuration
         Q_USE_PROVIDERNET_FOR_PUBLIC=True
         OVS_PHYSICAL_BRIDGE=br-ex
         PUBLIC_BRIDGE=br-ex
         OVS_BRIDGE_MAPPINGS=public:br-ex
 
 
-Adding Additional Compute Nodes
--------------------------------
-
-Let's suppose that after installing DevStack on the first host, you
-also want to do multinode testing and networking.
-
-Physical Network Setup
-~~~~~~~~~~~~~~~~~~~~~~
-
-.. image:: /assets/images/neutron-network-2.png
-   :alt: Network configuration for multiple DevStack nodes
-
-After DevStack installs and configures Neutron, traffic from guest VMs
-flows out of `devstack-2` (the compute node) and is encapsulated in a
-VXLAN tunnel back to `devstack-1` (the control node) where the L3
-agent is running.
-
-::
-
-    stack@devstack-2:~/devstack$ sudo ovs-vsctl show
-    8992d965-0ba0-42fd-90e9-20ecc528bc29
-        Bridge br-int
-            fail_mode: secure
-            Port br-int
-                Interface br-int
-                    type: internal
-            Port patch-tun
-                Interface patch-tun
-                    type: patch
-                    options: {peer=patch-int}
-        Bridge br-tun
-            fail_mode: secure
-            Port "vxlan-c0a801f6"
-                Interface "vxlan-c0a801f6"
-                    type: vxlan
-                    options: {df_default="true", in_key=flow, local_ip="172.18.161.7", out_key=flow, remote_ip="172.18.161.6"}
-            Port patch-int
-                Interface patch-int
-                    type: patch
-                    options: {peer=patch-tun}
-            Port br-tun
-                Interface br-tun
-                    type: internal
-        ovs_version: "2.0.2"
-
-Open vSwitch on the control node, where the L3 agent runs, is
-configured to de-encapsulate traffic from compute nodes, then forward
-it over the `br-ex` bridge, where `eth0` is attached.
-
-::
-
-    stack@devstack-1:~/devstack$ sudo ovs-vsctl show
-    422adeea-48d1-4a1f-98b1-8e7239077964
-        Bridge br-tun
-            fail_mode: secure
-            Port br-tun
-                Interface br-tun
-                    type: internal
-            Port patch-int
-                Interface patch-int
-                    type: patch
-                    options: {peer=patch-tun}
-            Port "vxlan-c0a801d8"
-                Interface "vxlan-c0a801d8"
-                    type: vxlan
-                    options: {df_default="true", in_key=flow, local_ip="172.18.161.6", out_key=flow, remote_ip="172.18.161.7"}
-        Bridge br-ex
-            Port phy-br-ex
-                Interface phy-br-ex
-                    type: patch
-                    options: {peer=int-br-ex}
-            Port "eth0"
-                Interface "eth0"
-            Port br-ex
-                Interface br-ex
-                    type: internal
-        Bridge br-int
-            fail_mode: secure
-            Port "tapce66332d-ea"
-                tag: 1
-                Interface "tapce66332d-ea"
-                    type: internal
-            Port "qg-65e5a4b9-15"
-                tag: 2
-                Interface "qg-65e5a4b9-15"
-                    type: internal
-            Port "qr-33e5e471-88"
-                tag: 1
-                Interface "qr-33e5e471-88"
-                    type: internal
-            Port "qr-acbe9951-70"
-                tag: 1
-                Interface "qr-acbe9951-70"
-                    type: internal
-            Port br-int
-                Interface br-int
-                    type: internal
-            Port patch-tun
-                Interface patch-tun
-                    type: patch
-                    options: {peer=patch-int}
-            Port int-br-ex
-                Interface int-br-ex
-                    type: patch
-                    options: {peer=phy-br-ex}
-        ovs_version: "2.0.2"
-
-`br-int` is a bridge that the Open vSwitch mechanism driver creates,
-which is used as the "integration bridge" where ports are created, and
-plugged into the virtual switching fabric. `br-ex` is an OVS bridge
-that is used to connect physical ports (like `eth0`), so that floating
-IP traffic for project networks can be received from the physical
-network infrastructure (and the internet), and routed to self service
-project network ports.  `br-tun` is a tunnel bridge that is used to
-connect OpenStack nodes (like `devstack-2`) together. This bridge is
-used so that project network traffic, using the VXLAN tunneling
-protocol, flows between each compute node where project instances run.
-
-DevStack Compute Configuration
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The host `devstack-2` has a very minimal `local.conf`.
-
-::
-
-    [[local|localrc]]
-    HOST_IP=172.18.161.7
-    SERVICE_HOST=172.18.161.6
-    MYSQL_HOST=172.18.161.6
-    RABBIT_HOST=172.18.161.6
-    GLANCE_HOSTPORT=172.18.161.6:9292
-    ADMIN_PASSWORD=secret
-    MYSQL_PASSWORD=secret
-    RABBIT_PASSWORD=secret
-    SERVICE_PASSWORD=secret
-
-    ## Neutron options
-    PUBLIC_INTERFACE=eth0
-    ENABLED_SERVICES=n-cpu,rabbit,q-agt,placement-client
-
-Network traffic from `eth0` on the compute nodes is then NAT'd by the
-controller node that runs Neutron's `neutron-l3-agent` and provides L3
-connectivity.
 
 
-Neutron Networking with Open vSwitch and Provider Networks
-==========================================================
 
-In some instances, it is desirable to use neutron's provider
-networking extension, so that networks that are configured on an
-external router can be utilized by neutron, and instances created via
-Nova can attach to the network managed by the external router.
+Using Neutron with Multiple Interfaces
+======================================
 
-For example, in some lab environments, a hardware router has been
-pre-configured by another party, and an OpenStack developer has been
-given a VLAN tag and IP address range, so that instances created via
-DevStack will use the external router for L3 connectivity, as opposed
-to the neutron L3 service.
-
-Physical Network Setup
-----------------------
-
-.. image:: /assets/images/neutron-network-3.png
-   :alt: Network configuration for provider networks
-
-On a compute node, the first interface, eth0 is used for the OpenStack
-management (API, message bus, etc) as well as for ssh for an
-administrator to access the machine.
+The first interface, eth0 is used for the OpenStack management (API,
+message bus, etc) as well as for ssh for an administrator to access
+the machine.
 
 ::
 
         stack@compute:~$ ifconfig eth0
         eth0      Link encap:Ethernet  HWaddr bc:16:65:20:af:fc
-                  inet addr:10.0.0.3
+                  inet addr:192.168.1.18
 
 eth1 is manually configured at boot to not have an IP address.
 Consult your operating system documentation for the appropriate
@@ -269,6 +101,9 @@ contains:
 
 The second physical interface, eth1 is added to a bridge (in this case
 named br-ex), which is used to forward network traffic from guest VMs.
+Network traffic from eth1 on the compute nodes is then NAT'd by the
+controller node that runs Neutron's `neutron-l3-agent` and provides L3
+connectivity.
 
 ::
 
@@ -288,131 +123,10 @@ named br-ex), which is used to forward network traffic from guest VMs.
                     Interface "eth1"
 
 
-Service Configuration
----------------------
-
-**Control Node**
-
-In this example, the control node will run the majority of the
-OpenStack API and management services (keystone, glance,
-nova, neutron)
-
-
-**Compute Nodes**
-
-In this example, the nodes that will host guest instances will run
-the ``neutron-openvswitch-agent`` for network connectivity, as well as
-the compute service ``nova-compute``.
-
-DevStack Configuration
-----------------------
-
-.. _ovs-provider-network-controller:
-
-The following is a snippet of the DevStack configuration on the
-controller node.
-
-::
-
-        HOST_IP=10.0.0.2
-        SERVICE_HOST=10.0.0.2
-        MYSQL_HOST=10.0.0.2
-        RABBIT_HOST=10.0.0.2
-        GLANCE_HOSTPORT=10.0.0.2:9292
-        PUBLIC_INTERFACE=eth1
-
-        ADMIN_PASSWORD=secret
-        MYSQL_PASSWORD=secret
-        RABBIT_PASSWORD=secret
-        SERVICE_PASSWORD=secret
-
-        ## Neutron options
-        Q_USE_SECGROUP=True
-        ENABLE_TENANT_VLANS=True
-        TENANT_VLAN_RANGE=3001:4000
-        PHYSICAL_NETWORK=default
-        OVS_PHYSICAL_BRIDGE=br-ex
-
-        Q_USE_PROVIDER_NETWORKING=True
-
-        disable_service q-l3
-
-        ## Neutron Networking options used to create Neutron Subnets
-
-        IPV4_ADDRS_SAFE_TO_USE="203.0.113.0/24"
-        NETWORK_GATEWAY=203.0.113.1
-        PROVIDER_SUBNET_NAME="provider_net"
-        PROVIDER_NETWORK_TYPE="vlan"
-        SEGMENTATION_ID=2010
-        USE_SUBNETPOOL=False
-
-In this configuration we are defining IPV4_ADDRS_SAFE_TO_USE to be a
-publicly routed IPv4 subnet. In this specific instance we are using
-the special TEST-NET-3 subnet defined in `RFC 5737 <https://tools.ietf.org/html/rfc5737>`_,
-which is used for documentation.  In your DevStack setup, IPV4_ADDRS_SAFE_TO_USE
-would be a public IP address range that you or your organization has
-allocated to you, so that you could access your instances from the
-public internet.
-
-The following is the DevStack configuration on
-compute node 1.
-
-::
-
-        HOST_IP=10.0.0.3
-        SERVICE_HOST=10.0.0.2
-        MYSQL_HOST=10.0.0.2
-        RABBIT_HOST=10.0.0.2
-        GLANCE_HOSTPORT=10.0.0.2:9292
-        ADMIN_PASSWORD=secret
-        MYSQL_PASSWORD=secret
-        RABBIT_PASSWORD=secret
-        SERVICE_PASSWORD=secret
-
-        # Services that a compute node runs
-        ENABLED_SERVICES=n-cpu,rabbit,q-agt
-
-        ## Open vSwitch provider networking options
-        PHYSICAL_NETWORK=default
-        OVS_PHYSICAL_BRIDGE=br-ex
-        PUBLIC_INTERFACE=eth1
-        Q_USE_PROVIDER_NETWORKING=True
-
-Compute node 2's configuration will be exactly the same, except
-``HOST_IP`` will be ``10.0.0.4``
-
-When DevStack is configured to use provider networking (via
-``Q_USE_PROVIDER_NETWORKING`` is True) -
-DevStack will automatically add the network interface defined in
-``PUBLIC_INTERFACE`` to the ``OVS_PHYSICAL_BRIDGE``
-
-For example, with the above  configuration, a bridge is
-created, named ``br-ex`` which is managed by Open vSwitch, and the
-second interface on the compute node, ``eth1`` is attached to the
-bridge, to forward traffic sent by guest VMs.
-
-Miscellaneous Tips
-==================
-
-Non-Standard MTU on the Physical Network
-----------------------------------------
-
-Neutron by default uses a MTU of 1500 bytes, which is
-the standard MTU for Ethernet.
-
-A different MTU can be specified by adding the following to
-the Neutron section of `local.conf`. For example,
-if you have network equipment that supports jumbo frames, you could
-set the MTU to 9000 bytes by adding the following
-
-::
-
-    [[post-config|/$Q_PLUGIN_CONF_FILE]]
-    global_physnet_mtu = 9000
 
 
 Disabling Next Generation Firewall Tools
-----------------------------------------
+========================================
 
 DevStack does not properly operate with modern firewall tools.  Specifically
 it will appear as if the guest VM can access the external network via ICMP,
@@ -442,145 +156,148 @@ disable ufw if it was enabled, do the following:
         sudo service iptables save
         sudo ufw disable
 
-Configuring Extension Drivers for the ML2 Plugin
-------------------------------------------------
-
-Extension drivers for the ML2 plugin are set with the variable
-``Q_ML2_PLUGIN_EXT_DRIVERS``, and includes the 'port_security' extension
-by default. If you want to remove all the extension drivers (even
-'port_security'), set ``Q_ML2_PLUGIN_EXT_DRIVERS`` to blank.
 
 
-Using Linux Bridge instead of Open vSwitch
-------------------------------------------
 
-The configuration for using the Linux Bridge ML2 driver is fairly
-straight forward. The Linux Bridge configuration for DevStack is similar
-to the :ref:`Open vSwitch based single interface <single-interface-ovs>`
-setup, with small modifications for the interface mappings.
+Neutron Networking with Open vSwitch
+====================================
 
+Configuring neutron, OpenStack Networking in DevStack is very similar to
+configuring `nova-network` - many of the same configuration variables
+(like `FIXED_RANGE` and `FLOATING_RANGE`) used by `nova-network` are
+used by neutron, which is intentional.
+
+The only difference is the disabling of `nova-network` in your
+local.conf, and the enabling of the neutron components.
+
+
+Configuration
+-------------
 
 ::
 
-    [[local|localrc]]
-    HOST_IP=172.18.161.6
-    SERVICE_HOST=172.18.161.6
-    MYSQL_HOST=172.18.161.6
-    RABBIT_HOST=172.18.161.6
-    GLANCE_HOSTPORT=172.18.161.6:9292
-    ADMIN_PASSWORD=secret
-    DATABASE_PASSWORD=secret
-    RABBIT_PASSWORD=secret
-    SERVICE_PASSWORD=secret
+        FIXED_RANGE=10.0.0.0/24
+        FLOATING_RANGE=192.168.27.0/24
+        PUBLIC_NETWORK_GATEWAY=192.168.27.2
 
-    ## Neutron options
-    Q_USE_SECGROUP=True
-    FLOATING_RANGE="172.18.161.0/24"
-    IPV4_ADDRS_SAFE_TO_USE="10.0.0.0/24"
-    Q_FLOATING_ALLOCATION_POOL=start=172.18.161.250,end=172.18.161.254
-    PUBLIC_NETWORK_GATEWAY="172.18.161.1"
-    PUBLIC_INTERFACE=eth0
+        disable_service n-net
+        enable_service q-svc
+        enable_service q-agt
+        enable_service q-dhcp
+        enable_service q-meta
+        enable_service q-l3
 
-    Q_USE_PROVIDERNET_FOR_PUBLIC=True
+        Q_USE_SECGROUP=True
+        ENABLE_TENANT_VLANS=True
+        TENANT_VLAN_RANGE=1000:1999
+        PHYSICAL_NETWORK=default
+        OVS_PHYSICAL_BRIDGE=br-ex
 
-    # Linuxbridge Settings
-    Q_AGENT=linuxbridge
-    LB_PHYSICAL_INTERFACE=eth0
-    PUBLIC_PHYSICAL_NETWORK=default
-    LB_INTERFACE_MAPPINGS=default:eth0
+In this configuration we are defining FLOATING_RANGE to be a
+subnet that exists in the private RFC1918 address space - however in
+in a real setup FLOATING_RANGE would be a public IP address range.
 
-Using MacVTap instead of Open vSwitch
-------------------------------------------
+Note that extension drivers for the ML2 plugin is set by
+`Q_ML2_PLUGIN_EXT_DRIVERS`, and it includes 'port_security' by default. If you
+want to remove all the extension drivers (even 'port_security'), set
+`Q_ML2_PLUGIN_EXT_DRIVERS` to blank.
 
-Security groups are not supported by the MacVTap agent. Due to that, devstack
-configures the NoopFirewall driver on the compute node.
+Neutron Networking with Open vSwitch and Provider Networks
+==========================================================
 
-MacVTap agent does not support l3, dhcp and metadata agent. Due to that you can
-chose between the following deployment scenarios:
+In some instances, it is desirable to use neutron's provider
+networking extension, so that networks that are configured on an
+external router can be utilized by neutron, and instances created via
+Nova can attach to the network managed by the external router.
 
-Single node with provider networks using config drive and external l3, dhcp
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-This scenario applies, if l3 and dhcp services are provided externally, or if
-you do not require them.
+For example, in some lab environments, a hardware router has been
+pre-configured by another party, and an OpenStack developer has been
+given a VLAN tag and IP address range, so that instances created via
+DevStack will use the external router for L3 connectivity, as opposed
+to the neutron L3 service.
 
 
+Service Configuration
+---------------------
+
+**Control Node**
+
+In this example, the control node will run the majority of the
+OpenStack API and management services (keystone, glance,
+nova, neutron)
+
+
+**Compute Nodes**
+
+In this example, the nodes that will host guest instances will run
+the `neutron-openvswitch-agent` for network connectivity, as well as
+the compute service `nova-compute`.
+
+DevStack Configuration
+----------------------
+
+The following is a snippet of the DevStack configuration on the
+controller node.
+
 ::
 
-    [[local|localrc]]
-    HOST_IP=10.0.0.2
-    SERVICE_HOST=10.0.0.2
-    MYSQL_HOST=10.0.0.2
-    RABBIT_HOST=10.0.0.2
-    ADMIN_PASSWORD=secret
-    MYSQL_PASSWORD=secret
-    RABBIT_PASSWORD=secret
-    SERVICE_PASSWORD=secret
+        PUBLIC_INTERFACE=eth1
 
-    Q_ML2_PLUGIN_MECHANISM_DRIVERS=macvtap
-    Q_USE_PROVIDER_NETWORKING=True
+        ## Neutron options
+        Q_USE_SECGROUP=True
+        ENABLE_TENANT_VLANS=True
+        TENANT_VLAN_RANGE=3001:4000
+        PHYSICAL_NETWORK=default
+        OVS_PHYSICAL_BRIDGE=br-ex
 
-    enable_plugin neutron https://opendev.org/openstack/neutron
+        Q_USE_PROVIDER_NETWORKING=True
+        Q_L3_ENABLED=False
 
-    ## MacVTap agent options
-    Q_AGENT=macvtap
-    PHYSICAL_NETWORK=default
+        # Do not use Nova-Network
+        disable_service n-net
 
-    IPV4_ADDRS_SAFE_TO_USE="203.0.113.0/24"
-    NETWORK_GATEWAY=203.0.113.1
-    PROVIDER_SUBNET_NAME="provider_net"
-    PROVIDER_NETWORK_TYPE="vlan"
-    SEGMENTATION_ID=2010
-    USE_SUBNETPOOL=False
+        # Neutron
+        ENABLED_SERVICES+=,q-svc,q-dhcp,q-meta,q-agt
 
-    [[post-config|/$Q_PLUGIN_CONF_FILE]]
-    [macvtap]
-    physical_interface_mappings = $PHYSICAL_NETWORK:eth1
+        ## Neutron Networking options used to create Neutron Subnets
 
-    [[post-config|$NOVA_CONF]]
-    force_config_drive = True
+        FIXED_RANGE="203.0.113.0/24"
+        PROVIDER_SUBNET_NAME="provider_net"
+        PROVIDER_NETWORK_TYPE="vlan"
+        SEGMENTATION_ID=2010
 
+In this configuration we are defining FIXED_RANGE to be a
+publicly routed IPv4 subnet. In this specific instance we are using
+the special TEST-NET-3 subnet defined in `RFC 5737 <http://tools.ietf.org/html/rfc5737>`_,
+which is used for documentation.  In your DevStack setup, FIXED_RANGE
+would be a public IP address range that you or your organization has
+allocated to you, so that you could access your instances from the
+public internet.
 
-Multi node with MacVTap compute node
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-This scenario applies, if you require OpenStack provided l3, dhcp or metadata
-services. Those are hosted on a separate controller and network node, running
-some other l2 agent technology (in this example Open vSwitch). This node needs
-to be configured for VLAN tenant networks.
-
-For OVS, a similar configuration like described in the
-:ref:`OVS Provider Network <ovs-provider-network-controller>` section can be
-used. Just add the following line to this local.conf, which also loads
-the MacVTap mechanism driver:
+The following is a snippet of the DevStack configuration on the
+compute node.
 
 ::
 
-    [[local|localrc]]
-    ...
-    Q_ML2_PLUGIN_MECHANISM_DRIVERS=openvswitch,linuxbridge,macvtap
-    ...
+        # Services that a compute node runs
+        ENABLED_SERVICES=n-cpu,rabbit,q-agt
 
-For the MacVTap compute node, use this local.conf:
+        ## Neutron options
+        Q_USE_SECGROUP=True
+        ENABLE_TENANT_VLANS=True
+        TENANT_VLAN_RANGE=3001:4000
+        PHYSICAL_NETWORK=default
+        OVS_PHYSICAL_BRIDGE=br-ex
+        PUBLIC_INTERFACE=eth1
+        Q_USE_PROVIDER_NETWORKING=True
+        Q_L3_ENABLED=False
 
-::
+When DevStack is configured to use provider networking (via
+`Q_USE_PROVIDER_NETWORKING` is True and `Q_L3_ENABLED` is False) -
+DevStack will automatically add the network interface defined in
+`PUBLIC_INTERFACE` to the `OVS_PHYSICAL_BRIDGE`
 
-    HOST_IP=10.0.0.3
-    SERVICE_HOST=10.0.0.2
-    MYSQL_HOST=10.0.0.2
-    RABBIT_HOST=10.0.0.2
-    ADMIN_PASSWORD=secret
-    MYSQL_PASSWORD=secret
-    RABBIT_PASSWORD=secret
-    SERVICE_PASSWORD=secret
-
-    # Services that a compute node runs
-    disable_all_services
-    enable_plugin neutron https://opendev.org/openstack/neutron
-    ENABLED_SERVICES+=n-cpu,q-agt
-
-    ## MacVTap agent options
-    Q_AGENT=macvtap
-    PHYSICAL_NETWORK=default
-
-    [[post-config|/$Q_PLUGIN_CONF_FILE]]
-    [macvtap]
-    physical_interface_mappings = $PHYSICAL_NETWORK:eth1
+For example, with the above  configuration, a bridge is
+created, named `br-ex` which is managed by Open vSwitch, and the
+second interface on the compute node, `eth1` is attached to the
+bridge, to forward traffic sent by guest VMs.

doc/source/guides/nova.rst

@@ -10,10 +10,10 @@ nova-serialproxy
 ================
 
 In Juno, nova implemented a `spec
-<https://specs.openstack.org/openstack/nova-specs/specs/juno/implemented/serial-ports.html>`_
+<http://specs.openstack.org/openstack/nova-specs/specs/juno/implemented/serial-ports.html>`_
 to allow read/write access to the serial console of an instance via
 `nova-serialproxy
-<https://docs.openstack.org/nova/latest/cli/nova-serialproxy.html>`_.
+<http://docs.openstack.org/developer/nova/man/nova-serialproxy.html>`_.
 
 The service can be enabled by adding ``n-sproxy`` to
 ``ENABLED_SERVICES``.  Further options can be enabled via
@@ -62,75 +62,11 @@ The service can be enabled by adding ``n-sproxy`` to
 
 Enabling the service is enough to be functional for a single machine DevStack.
 
-These config options are defined in `nova.conf.serial_console
-<https://opendev.org/openstack/nova/src/master/nova/conf/serial_console.py>`_.
+These config options are defined in `nova.console.serial
+<https://github.com/openstack/nova/blob/master/nova/console/serial.py#L33-L52>`_
+and `nova.cmd.serialproxy
+<https://github.com/openstack/nova/blob/master/nova/cmd/serialproxy.py#L26-L33>`_.
 
 For more information on OpenStack configuration see the `OpenStack
-Compute Service Configuration Reference
-<https://docs.openstack.org/nova/latest/admin/configuration/index.html>`_
-
-
-Fake virt driver
-================
-
-Nova has a `fake virt driver`_ which can be used for scale testing the control
-plane services or testing "move" operations between fake compute nodes, for
-example cold/live migration, evacuate and unshelve.
-
-The fake virt driver does not communicate with any hypervisor, it just reports
-some fake resource inventory values and keeps track of the state of the
-"guests" created, moved and deleted. It is not feature-complete with the
-compute API but is good enough for most API testing, and is also used within
-the nova functional tests themselves so is fairly robust.
-
-.. _fake virt driver: https://opendev.org/openstack/nova/src/branch/master/nova/virt/fake.py
-
-Configuration
--------------
-
-Set the following in your devstack ``local.conf``:
-
-.. code-block:: ini
-
-  [[local|localrc]]
-  VIRT_DRIVER=fake
-  NUMBER_FAKE_NOVA_COMPUTE=<number>
-
-The ``NUMBER_FAKE_NOVA_COMPUTE`` variable controls the number of fake
-``nova-compute`` services to run and defaults to 1.
-
-When ``VIRT_DRIVER=fake`` is used, devstack will disable quota checking in
-nova and neutron automatically. However, other services, like cinder, will
-still enforce quota limits by default.
-
-Scaling
--------
-
-The actual value to use for ``NUMBER_FAKE_NOVA_COMPUTE`` depends on factors
-such as:
-
-* The size of the host (physical or virtualized) on which devstack is running.
-* The number of API workers. By default, devstack will run ``max($nproc/2, 2)``
-  workers per API service. If you are running several fake compute services on
-  a single host, then consider setting ``API_WORKERS=1`` in ``local.conf``.
-
-In addition, while quota will be disabled in neutron, there is no fake ML2
-backend for neutron so creating fake VMs will still result in real ports being
-created. To create servers without networking, you can specify ``--nic=none``
-when creating the server, for example:
-
-.. code-block:: shell
-
-  $ openstack --os-compute-api-version 2.37 server create --flavor cirros256 \
-      --image cirros-0.6.3-x86_64-disk --nic none --wait test-server
-
-.. note:: ``--os-compute-api-version`` greater than or equal to 2.37 is
-          required to use ``--nic=none``.
-
-To avoid overhead from other services which you may not need, disable them in
-your ``local.conf``, for example:
-
-.. code-block:: ini
-
-  disable_service horizon
-  disable_service tempest
+Configuration Reference
+<http://docs.openstack.org/trunk/config-reference/content/list-of-compute-config-options.html>`_

doc/source/guides/single-machine.rst

@@ -45,45 +45,31 @@ We need to add a user to install DevStack. (if you created a user during
 install you can skip this step and just give the user sudo privileges
 below)
 
-.. code-block:: console
+::
 
-    $ sudo useradd -s /bin/bash -d /opt/stack -m stack
-
-Ensure home directory for the ``stack`` user has executable permission for all,
-as RHEL based distros create it with ``700`` and Ubuntu 21.04+ with ``750``
-which can cause issues during deployment.
-
-.. code-block:: console
-
-    $ sudo chmod +x /opt/stack
+    adduser stack
 
 Since this user will be making many changes to your system, it will need
 to have sudo privileges:
 
-.. code-block:: console
+::
 
-    $ apt-get install sudo -y || yum install -y sudo
-    $ echo "stack ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/stack
-
-.. note:: On some systems you may need to use ``sudo visudo``.
+    apt-get install sudo -y || yum install -y sudo
+    echo "stack ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers
 
 From here on you should use the user you created. **Logout** and
-**login** as that user:
-
-.. code-block:: console
-
-    $ sudo su stack && cd ~
+**login** as that user.
 
 Download DevStack
 -----------------
 
 We'll grab the latest version of DevStack via https:
 
-.. code-block:: console
+::
 
-    $ sudo apt-get install git -y || sudo yum install -y git
-    $ git clone https://opendev.org/openstack/devstack
-    $ cd devstack
+    sudo apt-get install git -y || sudo yum install -y git
+    git clone https://git.openstack.org/openstack-dev/devstack
+    cd devstack
 
 Run DevStack
 ------------
@@ -95,8 +81,11 @@ do the following:
 -  Set ``FLOATING_RANGE`` to a range not used on the local network, i.e.
    192.168.1.224/27. This configures IP addresses ending in 225-254 to
    be used as floating IPs.
--  Set ``FIXED_RANGE`` to configure the internal address space used by the
-   instances.
+-  Set ``FIXED_RANGE`` and ``FIXED_NETWORK_SIZE`` to configure the
+   internal address space used by the instances.
+-  Set ``FLAT_INTERFACE`` to the Ethernet interface that connects the
+   host to your local network. This is the interface that should be
+   configured with the static IP address mentioned above.
 -  Set the administrative password. This password is used for the
    **admin** and **demo** accounts set up as OpenStack users.
 -  Set the MySQL administrative password. The default here is a random
@@ -106,29 +95,26 @@ do the following:
 -  Set the service password. This is used by the OpenStack services
    (Nova, Glance, etc) to authenticate with Keystone.
 
-.. warning:: Only use alphanumeric characters in your passwords, as some
-   services fail to work when using special characters.
-
 ``local.conf`` should look something like this:
 
-.. code-block:: ini
+::
 
     [[local|localrc]]
     FLOATING_RANGE=192.168.1.224/27
     FIXED_RANGE=10.11.12.0/24
+    FIXED_NETWORK_SIZE=256
+    FLAT_INTERFACE=eth0
     ADMIN_PASSWORD=supersecret
-    DATABASE_PASSWORD=iheartdatabases
+    MYSQL_PASSWORD=iheartdatabases
     RABBIT_PASSWORD=flopsymopsy
     SERVICE_PASSWORD=iheartksl
-
-.. note:: There is a sample :download:`local.conf </assets/local.conf>` file
-    under the *samples* directory in the devstack repository.
+    SERVICE_TOKEN=xyzpdqlazydog
 
 Run DevStack:
 
-.. code-block:: console
+::
 
-    $ ./stack.sh
+    ./stack.sh
 
 A seemingly endless stream of activity ensues. When complete you will
 see a summary of ``stack.sh``'s work, including the relevant URLs,
@@ -142,3 +128,7 @@ computers on the local network. In this example that would be
 http://192.168.1.201/ for the dashboard (aka Horizon). Launch VMs and if
 you give them floating IPs and security group access those VMs will be
 accessible from other machines on your network.
+
+Some examples of using the OpenStack command-line clients ``nova`` and
+``glance`` are in the shakedown scripts in ``devstack/exercises``.
+``exercise.sh`` will run all of those scripts and report on the results.

doc/source/guides/single-vm.rst

@@ -60,13 +60,14 @@ passed as the user-data file when booting the VM.
             DEBIAN_FRONTEND=noninteractive sudo apt-get install -qqy git || sudo yum install -qy git
             sudo chown stack:stack /home/stack
             cd /home/stack
-            git clone https://opendev.org/openstack/devstack
+            git clone https://git.openstack.org/openstack-dev/devstack
             cd devstack
             echo '[[local|localrc]]' > local.conf
             echo ADMIN_PASSWORD=password >> local.conf
-            echo DATABASE_PASSWORD=password >> local.conf
+            echo MYSQL_PASSWORD=password >> local.conf
             echo RABBIT_PASSWORD=password >> local.conf
             echo SERVICE_PASSWORD=password >> local.conf
+            echo SERVICE_TOKEN=tokentoken >> local.conf
             ./stack.sh
         path: /home/stack/start.sh
         permissions: 0755
@@ -78,7 +79,7 @@ As DevStack will refuse to run as root, this configures ``cloud-init``
 to create a non-root user and run the ``start.sh`` script as that user.
 
 If you are using cloud-init and you have not
-:ref:`enabled custom logging <enable_logging>` of the stack
+`enabled custom logging <../configuration.html#enable-logging>`_ of the stack
 output, then the stack output can be found in
 ``/var/log/cloud-init-output.log`` by default.
 

doc/source/index.rst

@@ -1,180 +1,238 @@
-.. 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
-========
+DevStack - an OpenStack Community Production
+============================================
 
 .. image:: assets/images/logo-blue.png
 
-DevStack is a series of extensible scripts used to quickly bring up a
-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.
+.. toctree::
+   :glob:
+   :maxdepth: 1
 
-The source is available at `<https://opendev.org/openstack/devstack>`__.
-
-.. warning::
-
-   DevStack will make substantial changes to your system during
-   installation. Only run DevStack on servers or virtual machines that
-   are dedicated to this purpose.
+   overview
+   configuration
+   plugins
+   plugin-registry
+   faq
+   changes
+   hacking
 
 Quick Start
-+++++++++++
+-----------
 
-Install Linux
--------------
+#. Select a Linux Distribution
 
-Start with a clean and minimal install of a Linux system. DevStack
-attempts to support the two latest LTS releases of Ubuntu,
-Rocky Linux 9 and openEuler.
+   Only Ubuntu 14.04 (Trusty), Fedora 21 (or Fedora 22) and CentOS/RHEL
+   7 are documented here. OpenStack also runs and is packaged on other
+   flavors of Linux such as OpenSUSE and Debian.
 
-If you do not have a preference, Ubuntu 22.04 (Jammy) is the
-most tested, and will probably go the smoothest.
+#. Install Selected OS
 
-Add Stack User (optional)
--------------------------
+   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.
 
-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).
+#. Download DevStack
 
-If you are not using a cloud image, you can create a separate `stack` user
-to run DevStack with
+   ::
 
-.. code-block:: console
+       git clone https://git.openstack.org/openstack-dev/devstack
 
-   $ sudo useradd -s /bin/bash -d /opt/stack -m stack
+   The ``devstack`` repo contains a script that installs OpenStack and
+   templates for configuration files
 
-Ensure home directory for the ``stack`` user has executable permission for all,
-as RHEL based distros create it with ``700`` and Ubuntu 21.04+ with ``750``
-which can cause issues during deployment.
+#. Configure
 
-.. code-block:: console
+   We recommend at least a :ref:`minimal-configuration` be set up.
 
-    $ sudo chmod +x /opt/stack
+#. Start the install
 
-Since this user will be making many changes to your system, it should
-have sudo privileges:
+   ::
 
-.. code-block:: console
+       cd devstack; ./stack.sh
 
-    $ echo "stack ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/stack
-    $ sudo -u stack -i
+   It takes a few minutes, we recommend `reading the
+   script <stack.sh.html>`__ while it is building.
 
-Download DevStack
------------------
+Guides
+======
 
-.. code-block:: console
-
-   $ git clone https://opendev.org/openstack/devstack
-   $ cd 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 four passwords preset at the root of the
-devstack git repo.
-
-.. code-block:: ini
-
-   [[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.
-
-.. note:: There is a sample :download:`local.conf </assets/local.conf>` file
-   under the *samples* directory in the devstack repository.
-
-.. warning:: Only use alphanumeric characters in your passwords, as some
-   services fail to work when using special characters.
-
-Start the install
------------------
-
-.. code-block:: console
-
-   $ ./stack.sh
-
-This will take 15 - 30 minutes, largely depending on the speed of
-your internet connection. Many git trees and packages will be
-installed during this process.
-
-Profit!
--------
-
-You now have a working DevStack! Congrats!
-
-Your devstack will have installed ``keystone``, ``glance``, ``nova``,
-``placement``, ``cinder``, ``neutron``, and ``horizon``. Floating IPs
-will be available, guests have access to the external world.
-
-You can access horizon to experience the web interface to
-OpenStack, and manage vms, networks, volumes, and images from
-there.
-
-You can ``source openrc`` in your shell, and then use the
-``openstack`` command line tool to manage your devstack.
-
-You can :ref:`create a VM and SSH into it <ssh>`.
-
-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.
-
-Use devstack in your CI with :doc:`Ansible roles <zuul_roles>` and
-:doc:`Jobs <zuul_jobs>` for Zuul V3. Migrate your devstack Zuul V2 jobs to Zuul
-V3 with this full migration :doc:`how-to <zuul_ci_jobs_migration>`.
-
-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>`.
-
-If you are a new contributor to devstack please refer: :doc:`contributor/contributing`
-
-.. toctree::
-   :hidden:
-
-   contributor/contributing
-
-Contents
-++++++++
+Walk through various setups used by stackers
 
 .. toctree::
    :glob:
-   :maxdepth: 2
+   :maxdepth: 1
 
-   *
+   guides/single-vm
+   guides/single-machine
+   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>`
+
+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
+-------------
+
+:doc:`Configuring and customizing the stack <configuration>`
+
+Plugins
+-------
+
+:doc:`Extending DevStack with new features <plugins>`
+
+Recent Changes
+--------------
+
+:doc:`An incomplete summary of recent changes <changes>`
+
+FAQ
+---
+
+:doc:`The DevStack FAQ <faq>`
+
+Contributing
+------------
+
+:doc:`Pitching in to make DevStack a better place <hacking>`
+
+Code
+====
+
+*A look at the bits that make it all go*
+
+Scripts
+-------
+
+* `stack.sh <stack.sh.html>`__ - The main script
+* `functions <functions.html>`__ - DevStack-specific functions
+* `functions-common <functions-common.html>`__ - Functions shared with other projects
+* `lib/apache <lib/apache.html>`__
+* `lib/ceph <lib/ceph.html>`__
+* `lib/cinder <lib/cinder.html>`__
+* `lib/database <lib/database.html>`__
+* `lib/dstat <lib/dstat.html>`__
+* `lib/glance <lib/glance.html>`__
+* `lib/heat <lib/heat.html>`__
+* `lib/horizon <lib/horizon.html>`__
+* `lib/infra <lib/infra.html>`__
+* `lib/ironic <lib/ironic.html>`__
+* `lib/keystone <lib/keystone.html>`__
+* `lib/ldap <lib/ldap.html>`__
+* `lib/neutron-legacy <lib/neutron-legacy.html>`__
+* `lib/nova <lib/nova.html>`__
+* `lib/oslo <lib/oslo.html>`__
+* `lib/rpc\_backend <lib/rpc_backend.html>`__
+* `lib/swift <lib/swift.html>`__
+* `lib/tempest <lib/tempest.html>`__
+* `lib/tls <lib/tls.html>`__
+* `lib/trove <lib/trove.html>`__
+* `unstack.sh <unstack.sh.html>`__
+* `clean.sh <clean.sh.html>`__
+* `run\_tests.sh <run_tests.sh.html>`__
+
+* `extras.d/50-ironic.sh <extras.d/50-ironic.sh.html>`__
+* `extras.d/60-ceph.sh <extras.d/60-ceph.sh.html>`__
+* `extras.d/70-tuskar.sh <extras.d/70-tuskar.sh.html>`__
+* `extras.d/80-tempest.sh <extras.d/80-tempest.sh.html>`__
+
+* `inc/ini-config <inc/ini-config.html>`__
+* `inc/meta-config <inc/meta-config.html>`__
+* `inc/python <inc/python.html>`__
+
+* `pkg/elasticsearch.sh <pkg/elasticsearch.sh.html>`_
+
+Configuration
+-------------
+
+.. toctree::
+   :glob:
+   :maxdepth: 1
+
+   local.conf
+   stackrc
+   openrc
+   exerciserc
+   eucarc
+
+Tools
+-----
+
+* `tools/build\_docs.sh <tools/build_docs.sh.html>`__
+* `tools/build\_venv.sh <tools/build_venv.sh.html>`__
+* `tools/create-stack-user.sh <tools/create-stack-user.sh.html>`__
+* `tools/create\_userrc.sh <tools/create_userrc.sh.html>`__
+* `tools/fixup\_stuff.sh <tools/fixup_stuff.sh.html>`__
+* `tools/info.sh <tools/info.sh.html>`__
+* `tools/install\_pip.sh <tools/install_pip.sh.html>`__
+* `tools/install\_prereqs.sh <tools/install_prereqs.sh.html>`__
+* `tools/make\_cert.sh <tools/make_cert.sh.html>`__
+* `tools/upload\_image.sh <tools/upload_image.sh.html>`__
+
+Samples
+-------
+
+* `local.sh <samples/local.sh.html>`__
+
+Exercises
+---------
+
+* `exercise.sh <exercise.sh.html>`__
+* `exercises/aggregates.sh <exercises/aggregates.sh.html>`__
+* `exercises/boot\_from\_volume.sh <exercises/boot_from_volume.sh.html>`__
+* `exercises/bundle.sh <exercises/bundle.sh.html>`__
+* `exercises/client-args.sh <exercises/client-args.sh.html>`__
+* `exercises/client-env.sh <exercises/client-env.sh.html>`__
+* `exercises/euca.sh <exercises/euca.sh.html>`__
+* `exercises/floating\_ips.sh <exercises/floating_ips.sh.html>`__
+* `exercises/horizon.sh <exercises/horizon.sh.html>`__
+* `exercises/neutron-adv-test.sh <exercises/neutron-adv-test.sh.html>`__
+* `exercises/sec\_groups.sh <exercises/sec_groups.sh.html>`__
+* `exercises/swift.sh <exercises/swift.sh.html>`__
+* `exercises/volumes.sh <exercises/volumes.sh.html>`__

doc/source/local.conf.rst

@@ -0,0 +1,9 @@
+==========================
+local.conf - User Settings
+==========================
+
+``local.conf`` is a user-maintained settings file that is sourced in
+``stackrc``. It contains a section that replaces the historical
+``localrc`` file. See the description of
+:doc:`local.conf <configuration>` for more details about the mechanics
+of the file.

doc/source/networking.rst

@@ -1,238 +0,0 @@
-=====================
- 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 its 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 a subnet allocated from
-  the 10.0.0.0/22 range
-* a ``br-ex`` interface controlled by neutron for all its networking
-  (this is not connected to any physical interfaces).
-* DNS resolution for guests based on the resolv.conf for your 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 your guests accessible from 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 lose 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.0/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.
-
-
-Private Network Addressing
-==========================
-
-The private networks addresses are controlled by the ``IPV4_ADDRS_SAFE_TO_USE``
-and the ``IPV6_ADDRS_SAFE_TO_USE`` variables. This allows users to specify one
-single variable of safe internal IPs to use that will be referenced whether or
-not subnetpools are in use.
-
-For IPv4, ``FIXED_RANGE`` and ``SUBNETPOOL_PREFIX_V4`` will just default to
-the value of ``IPV4_ADDRS_SAFE_TO_USE`` directly.
-
-For IPv6, ``FIXED_RANGE_V6`` will default to the first /64 of the value of
-``IPV6_ADDRS_SAFE_TO_USE``. If ``IPV6_ADDRS_SAFE_TO_USE`` is /64 or smaller,
-``FIXED_RANGE_V6`` will just use the value of that directly.
-``SUBNETPOOL_PREFIX_V6`` will just default to the value of
-``IPV6_ADDRS_SAFE_TO_USE`` directly.
-
-.. _ssh:
-
-SSH access to instances
-=======================
-
-To validate connectivity, you can create an instance using the
-``$PRIVATE_NETWORK_NAME`` network (default: ``private``), create a floating IP
-using the ``$PUBLIC_NETWORK_NAME`` network (default: ``public``), and attach
-this floating IP to the instance:
-
-.. code-block:: shell
-
-    openstack keypair create --public-key ~/.ssh/id_rsa.pub test-keypair
-    openstack server create --network private --key-name test-keypair ... test-server
-    fip_id=$(openstack floating ip create public -f value -c id)
-    openstack server add floating ip test-server ${fip_id}
-
-Once done, ensure you have enabled SSH and ICMP (ping) access for the security
-group used for the instance. You can either create a custom security group and
-specify it when creating the instance or add it after creation, or you can
-modify the ``default`` security group created by default for each project.
-Let's do the latter:
-
-.. code-block:: shell
-
-    openstack security group rule create --proto icmp --dst-port 0 default
-    openstack security group rule create --proto tcp --dst-port 22 default
-
-Finally, SSH into the instance. If you used the Cirros instance uploaded by
-default, then you can run the following:
-
-.. code-block:: shell
-
-    openstack server ssh test-server -- -l cirros
-
-This will connect using the ``cirros`` user and the keypair you configured when
-creating the instance.
-
-Remote SSH access to instances
-==============================
-
-You can also SSH to created instances on your DevStack host from other hosts.
-This can be helpful if you are e.g. deploying DevStack in a VM on an existing
-cloud and wish to do development on your local machine. There are a few ways to
-do this.
-
-.. rubric:: Configure instances to be locally accessible
-
-The most obvious way is to configure guests to be locally accessible, as
-described `above <Locally Accessible Guests>`__. This has the advantage of
-requiring no further effort on the client. However, it is more involved and
-requires either support from your cloud or some inadvisable workarounds.
-
-.. rubric:: Use your DevStack host as a jump host
-
-You can choose to use your DevStack host as a jump host. To SSH to a instance
-this way, pass the standard ``-J`` option to the ``openstack ssh`` / ``ssh``
-command. For example:
-
-.. code-block::
-
-    openstack server ssh test-server -- -l cirros -J username@devstack-host
-
-(where ``test-server`` is name of an existing instance, as described
-:ref:`previously <ssh>`, and ``username`` and ``devstack-host`` are the
-username and hostname of your DevStack host).
-
-This can also be configured via your ``~/.ssh/config`` file, making it rather
-effortless. However, it only allows SSH access. If you want to access e.g. a
-web application on the instance, you will need to configure an SSH tunnel and
-forward select ports using the ``-L`` option. For example, to forward HTTP
-traffic:
-
-.. code-block::
-
-    openstack server ssh test-server -- -l cirros -L 8080:username@devstack-host:80
-
-(where ``test-server`` is name of an existing instance, as described
-:ref:`previously <ssh>`, and ``username`` and ``devstack-host`` are the
-username and hostname of your DevStack host).
-
-As you can imagine, this can quickly get out of hand, particularly for more
-complex guest applications with multiple ports.
-
-.. rubric:: Use a proxy or VPN tool
-
-You can use a proxy or VPN tool to enable tunneling for the floating IP
-address range of the ``$PUBLIC_NETWORK_NAME`` network (default: ``public``)
-defined by ``$FLOATING_RANGE`` (default: ``172.24.4.0/24``). There are many
-such tools available to do this. For example, we could use a useful utility
-called `shuttle`__. To enable tunneling using ``shuttle``, first ensure you
-have allowed SSH and HTTP(S) traffic to your DevStack host. Allowing HTTP(S)
-traffic is necessary so you can use the OpenStack APIs remotely. How you do
-this will depend on where your DevStack host is running. Once this is done,
-install ``sshuttle`` on your localhost:
-
-.. code-block:: bash
-
-    sudo apt-get install sshuttle || yum install sshuttle
-
-Finally, start ``sshuttle`` on your localhost using the floating IP address
-range. For example, assuming you are using the default value for
-``$FLOATING_RANGE``, you can do:
-
-.. code-block:: bash
-
-    sshuttle -r username@devstack-host 172.24.4.0/24
-
-(where ``username`` and ``devstack-host`` are the username and hostname of your
-DevStack host).
-
-You should now be able to create an instance and SSH into it:
-
-.. code-block:: bash
-
-    openstack server ssh test-server -- -l cirros
-
-(where ``test-server`` is name of an existing instance, as described
-:ref:`previously <ssh>`)
-
-.. __: https://github.com/sshuttle/sshuttle

doc/source/openrc.rst

@@ -0,0 +1,68 @@
+=====================================
+openrc - User Authentication Settings
+=====================================
+
+``openrc`` configures login credentials suitable for use with the
+OpenStack command-line tools. ``openrc`` sources ``stackrc`` at the
+beginning (which in turn sources the ``localrc`` section of
+``local.conf``) in order to pick up ``HOST_IP`` and/or ``SERVICE_HOST``
+to use in the endpoints. The values shown below are the default values.
+
+OS\_PROJECT\_NAME (OS\_TENANT\_NAME)
+    Keystone has
+    standardized the term *project* as the entity that owns resources. In
+    some places references still exist to the previous term
+    *tenant* for this use. Also, *project\_name* is preferred to
+    *project\_id*.  OS\_TENANT\_NAME remains supported for compatibility
+    with older tools.
+
+    ::
+
+        OS_PROJECT_NAME=demo
+
+OS\_USERNAME
+    In addition to the owning entity (project), OpenStack calls the entity
+    performing the action *user*.
+
+    ::
+
+        OS_USERNAME=demo
+
+OS\_PASSWORD
+    Keystone's default authentication requires a password be provided.
+    The usual cautions about putting passwords in environment variables
+    apply, for most DevStack uses this may be an acceptable tradeoff.
+
+    ::
+
+        OS_PASSWORD=secrete
+
+HOST\_IP, SERVICE\_HOST
+    Set API endpoint host using ``HOST_IP``. ``SERVICE_HOST`` may also
+    be used to specify the endpoint, which is convenient for some
+    ``local.conf`` configurations. Typically, ``HOST_IP`` is set in the
+    ``localrc`` section.
+
+    ::
+
+        HOST_IP=127.0.0.1
+        SERVICE_HOST=$HOST_IP
+
+OS\_AUTH\_URL
+    Authenticating against an OpenStack cloud using Keystone returns a
+    *Token* and *Service Catalog*. The catalog contains the endpoints
+    for all services the user/tenant has access to - including Nova,
+    Glance, Keystone and Swift.
+
+    ::
+
+        OS_AUTH_URL=http://$SERVICE_HOST:5000/v2.0
+
+KEYSTONECLIENT\_DEBUG, NOVACLIENT\_DEBUG
+    Set command-line client log level to ``DEBUG``. These are commented
+    out by default.
+
+    ::
+
+        # export KEYSTONECLIENT_DEBUG=1
+        # export NOVACLIENT_DEBUG=1

doc/source/overview.rst

@@ -20,15 +20,16 @@ Base OS
 
 *The OpenStack Technical Committee (TC) has defined the current CI
 strategy to include the latest Ubuntu release and the latest RHEL
-release.*
+release (for Python 2.6 testing).*
 
 -  Ubuntu: current LTS release plus current development release
--  RHEL/CentOS/RockyLinux: current major release
+-  Fedora: current release plus previous release
+-  RHEL: current major release
 -  Other OS platforms may continue to be included but the maintenance of
    those platforms shall not be assumed simply due to their presence.
    Having a listed point-of-contact for each additional OS will greatly
    increase its chance of being well-maintained.
--  Patches for Ubuntu and/or RockyLinux will not be held up due to
+-  Patches for Ubuntu and/or Fedora will not be held up due to
    side-effects on other OS platforms.
 
 Databases
@@ -37,6 +38,7 @@ Databases
 *As packaged by the host OS*
 
 -  MySQL
+-  PostgreSQL
 
 Queues
 ------
@@ -44,6 +46,7 @@ Queues
 *As packaged by the host OS*
 
 -  Rabbit
+-  Qpid
 
 Web Server
 ----------
@@ -55,6 +58,9 @@ Web Server
 OpenStack Network
 -----------------
 
+*Defaults to nova network, optionally use neutron*
+
+-  Nova Network: FlatDHCP
 -  Neutron: A basic configuration approximating the original FlatDHCP
    mode using linuxbridge or OpenVSwitch.
 
@@ -62,9 +68,9 @@ Services
 --------
 
 The default services configured by DevStack are Identity (keystone),
-Object Storage (swift), Image Service (glance), Block Storage
-(cinder), Compute (nova), Placement (placement),
-Networking (neutron), Dashboard (horizon).
+Object Storage (swift), Image Service (glance), Block Storage (cinder),
+Compute (nova), Networking (nova), Dashboard (horizon), Orchestration
+(heat)
 
 Additional services not included directly in DevStack can be tied in to
 ``stack.sh`` using the :doc:`plugin mechanism <plugins>` to call
@@ -74,4 +80,13 @@ Node Configurations
 -------------------
 
 -  single node
--  multi-node configurations as are tested by the gate
+-  multi-node is not tested regularly by the core team, and even then
+   only minimal configurations are reviewed
+
+Exercises
+---------
+
+The DevStack exercise scripts are no longer used as integration and gate
+testing as that job has transitioned to Tempest. They are still
+maintained as a demonstrations of using OpenStack from the command line
+and for quick operational testing.

doc/source/plugin-registry.rst

@@ -1,180 +1,89 @@
-.. Note to patch submitters:
-
-   # ============================= #
-   # THIS FILE IS AUTOGENERATED !  #
-   # ============================= #
-
-   ** Plugins are found automatically and added to this list **
-
-   This file is created by a periodic proposal job.  You should not
-   edit this file.
-
-   You should edit the files data/devstack-plugins-registry.footer
-   data/devstack-plugins-registry.header to modify this text.
+..
+  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
 ==========================
 
-The following list is an automatically-generated collection of
-available DevStack plugins.  This includes, but is not limited to,
-official OpenStack projects.
+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            |
++------------------+---------------------------------------------+--------------------+
+|aodh              |git://git.openstack.org/openstack/aodh       | alarming           |
++------------------+---------------------------------------------+--------------------+
+|ceilometer        |git://git.openstack.org/openstack/ceilometer | metering           |
++------------------+---------------------------------------------+--------------------+
+|gnocchi           |git://git.openstack.org/openstack/gnocchi    | metric             |
++------------------+---------------------------------------------+--------------------+
+|magnum            |git://git.openstack.org/openstack/magnum     |                    |
++------------------+---------------------------------------------+--------------------+
+|manila            |git://git.openstack.org/openstack/manila     | file shares        |
++------------------+---------------------------------------------+--------------------+
+|mistral           |git://git.openstack.org/openstack/mistral    |                    |
++------------------+---------------------------------------------+--------------------+
+|rally             |git://git.openstack.org/openstack/rally      |                    |
++------------------+---------------------------------------------+--------------------+
+|sahara            |git://git.openstack.org/openstack/sahara     |                    |
++------------------+---------------------------------------------+--------------------+
+|trove             |git://git.openstack.org/openstack/trove      |                    |
++------------------+---------------------------------------------+--------------------+
+|zaqar             |git://git.openstack.org/openstack/zaqar      |                    |
++------------------+---------------------------------------------+--------------------+
 
 
-======================================== ===
-Plugin Name                              URL
-======================================== ===
-openstack/aodh                           `https://opendev.org/openstack/aodh <https://opendev.org/openstack/aodh>`__
-openstack/barbican                       `https://opendev.org/openstack/barbican <https://opendev.org/openstack/barbican>`__
-openstack/blazar                         `https://opendev.org/openstack/blazar <https://opendev.org/openstack/blazar>`__
-openstack/ceilometer                     `https://opendev.org/openstack/ceilometer <https://opendev.org/openstack/ceilometer>`__
-openstack/cloudkitty                     `https://opendev.org/openstack/cloudkitty <https://opendev.org/openstack/cloudkitty>`__
-openstack/cyborg                         `https://opendev.org/openstack/cyborg <https://opendev.org/openstack/cyborg>`__
-openstack/designate                      `https://opendev.org/openstack/designate <https://opendev.org/openstack/designate>`__
-openstack/devstack-plugin-amqp1          `https://opendev.org/openstack/devstack-plugin-amqp1 <https://opendev.org/openstack/devstack-plugin-amqp1>`__
-openstack/devstack-plugin-ceph           `https://opendev.org/openstack/devstack-plugin-ceph <https://opendev.org/openstack/devstack-plugin-ceph>`__
-openstack/devstack-plugin-container      `https://opendev.org/openstack/devstack-plugin-container <https://opendev.org/openstack/devstack-plugin-container>`__
-openstack/devstack-plugin-kafka          `https://opendev.org/openstack/devstack-plugin-kafka <https://opendev.org/openstack/devstack-plugin-kafka>`__
-openstack/devstack-plugin-nfs            `https://opendev.org/openstack/devstack-plugin-nfs <https://opendev.org/openstack/devstack-plugin-nfs>`__
-openstack/devstack-plugin-open-cas       `https://opendev.org/openstack/devstack-plugin-open-cas <https://opendev.org/openstack/devstack-plugin-open-cas>`__
-openstack/freezer                        `https://opendev.org/openstack/freezer <https://opendev.org/openstack/freezer>`__
-openstack/freezer-api                    `https://opendev.org/openstack/freezer-api <https://opendev.org/openstack/freezer-api>`__
-openstack/freezer-tempest-plugin         `https://opendev.org/openstack/freezer-tempest-plugin <https://opendev.org/openstack/freezer-tempest-plugin>`__
-openstack/freezer-web-ui                 `https://opendev.org/openstack/freezer-web-ui <https://opendev.org/openstack/freezer-web-ui>`__
-openstack/heat                           `https://opendev.org/openstack/heat <https://opendev.org/openstack/heat>`__
-openstack/heat-dashboard                 `https://opendev.org/openstack/heat-dashboard <https://opendev.org/openstack/heat-dashboard>`__
-openstack/ironic                         `https://opendev.org/openstack/ironic <https://opendev.org/openstack/ironic>`__
-openstack/ironic-inspector               `https://opendev.org/openstack/ironic-inspector <https://opendev.org/openstack/ironic-inspector>`__
-openstack/ironic-prometheus-exporter     `https://opendev.org/openstack/ironic-prometheus-exporter <https://opendev.org/openstack/ironic-prometheus-exporter>`__
-openstack/ironic-ui                      `https://opendev.org/openstack/ironic-ui <https://opendev.org/openstack/ironic-ui>`__
-openstack/keystone                       `https://opendev.org/openstack/keystone <https://opendev.org/openstack/keystone>`__
-openstack/kuryr-libnetwork               `https://opendev.org/openstack/kuryr-libnetwork <https://opendev.org/openstack/kuryr-libnetwork>`__
-openstack/magnum                         `https://opendev.org/openstack/magnum <https://opendev.org/openstack/magnum>`__
-openstack/magnum-ui                      `https://opendev.org/openstack/magnum-ui <https://opendev.org/openstack/magnum-ui>`__
-openstack/manila                         `https://opendev.org/openstack/manila <https://opendev.org/openstack/manila>`__
-openstack/manila-tempest-plugin          `https://opendev.org/openstack/manila-tempest-plugin <https://opendev.org/openstack/manila-tempest-plugin>`__
-openstack/manila-ui                      `https://opendev.org/openstack/manila-ui <https://opendev.org/openstack/manila-ui>`__
-openstack/masakari                       `https://opendev.org/openstack/masakari <https://opendev.org/openstack/masakari>`__
-openstack/mistral                        `https://opendev.org/openstack/mistral <https://opendev.org/openstack/mistral>`__
-openstack/monasca-api                    `https://opendev.org/openstack/monasca-api <https://opendev.org/openstack/monasca-api>`__
-openstack/monasca-events-api             `https://opendev.org/openstack/monasca-events-api <https://opendev.org/openstack/monasca-events-api>`__
-openstack/monasca-tempest-plugin         `https://opendev.org/openstack/monasca-tempest-plugin <https://opendev.org/openstack/monasca-tempest-plugin>`__
-openstack/networking-bagpipe             `https://opendev.org/openstack/networking-bagpipe <https://opendev.org/openstack/networking-bagpipe>`__
-openstack/networking-baremetal           `https://opendev.org/openstack/networking-baremetal <https://opendev.org/openstack/networking-baremetal>`__
-openstack/networking-bgpvpn              `https://opendev.org/openstack/networking-bgpvpn <https://opendev.org/openstack/networking-bgpvpn>`__
-openstack/networking-generic-switch      `https://opendev.org/openstack/networking-generic-switch <https://opendev.org/openstack/networking-generic-switch>`__
-openstack/networking-sfc                 `https://opendev.org/openstack/networking-sfc <https://opendev.org/openstack/networking-sfc>`__
-openstack/neutron                        `https://opendev.org/openstack/neutron <https://opendev.org/openstack/neutron>`__
-openstack/neutron-dynamic-routing        `https://opendev.org/openstack/neutron-dynamic-routing <https://opendev.org/openstack/neutron-dynamic-routing>`__
-openstack/neutron-fwaas                  `https://opendev.org/openstack/neutron-fwaas <https://opendev.org/openstack/neutron-fwaas>`__
-openstack/neutron-fwaas-dashboard        `https://opendev.org/openstack/neutron-fwaas-dashboard <https://opendev.org/openstack/neutron-fwaas-dashboard>`__
-openstack/neutron-tempest-plugin         `https://opendev.org/openstack/neutron-tempest-plugin <https://opendev.org/openstack/neutron-tempest-plugin>`__
-openstack/neutron-vpnaas                 `https://opendev.org/openstack/neutron-vpnaas <https://opendev.org/openstack/neutron-vpnaas>`__
-openstack/neutron-vpnaas-dashboard       `https://opendev.org/openstack/neutron-vpnaas-dashboard <https://opendev.org/openstack/neutron-vpnaas-dashboard>`__
-openstack/nova                           `https://opendev.org/openstack/nova <https://opendev.org/openstack/nova>`__
-openstack/octavia                        `https://opendev.org/openstack/octavia <https://opendev.org/openstack/octavia>`__
-openstack/octavia-dashboard              `https://opendev.org/openstack/octavia-dashboard <https://opendev.org/openstack/octavia-dashboard>`__
-openstack/octavia-tempest-plugin         `https://opendev.org/openstack/octavia-tempest-plugin <https://opendev.org/openstack/octavia-tempest-plugin>`__
-openstack/openstacksdk                   `https://opendev.org/openstack/openstacksdk <https://opendev.org/openstack/openstacksdk>`__
-openstack/osprofiler                     `https://opendev.org/openstack/osprofiler <https://opendev.org/openstack/osprofiler>`__
-openstack/ovn-bgp-agent                  `https://opendev.org/openstack/ovn-bgp-agent <https://opendev.org/openstack/ovn-bgp-agent>`__
-openstack/ovn-octavia-provider           `https://opendev.org/openstack/ovn-octavia-provider <https://opendev.org/openstack/ovn-octavia-provider>`__
-openstack/rally-openstack                `https://opendev.org/openstack/rally-openstack <https://opendev.org/openstack/rally-openstack>`__
-openstack/shade                          `https://opendev.org/openstack/shade <https://opendev.org/openstack/shade>`__
-openstack/skyline-apiserver              `https://opendev.org/openstack/skyline-apiserver <https://opendev.org/openstack/skyline-apiserver>`__
-openstack/storlets                       `https://opendev.org/openstack/storlets <https://opendev.org/openstack/storlets>`__
-openstack/tacker                         `https://opendev.org/openstack/tacker <https://opendev.org/openstack/tacker>`__
-openstack/tap-as-a-service               `https://opendev.org/openstack/tap-as-a-service <https://opendev.org/openstack/tap-as-a-service>`__
-openstack/telemetry-tempest-plugin       `https://opendev.org/openstack/telemetry-tempest-plugin <https://opendev.org/openstack/telemetry-tempest-plugin>`__
-openstack/trove                          `https://opendev.org/openstack/trove <https://opendev.org/openstack/trove>`__
-openstack/trove-dashboard                `https://opendev.org/openstack/trove-dashboard <https://opendev.org/openstack/trove-dashboard>`__
-openstack/venus                          `https://opendev.org/openstack/venus <https://opendev.org/openstack/venus>`__
-openstack/venus-dashboard                `https://opendev.org/openstack/venus-dashboard <https://opendev.org/openstack/venus-dashboard>`__
-openstack/vitrage                        `https://opendev.org/openstack/vitrage <https://opendev.org/openstack/vitrage>`__
-openstack/vitrage-dashboard              `https://opendev.org/openstack/vitrage-dashboard <https://opendev.org/openstack/vitrage-dashboard>`__
-openstack/vitrage-tempest-plugin         `https://opendev.org/openstack/vitrage-tempest-plugin <https://opendev.org/openstack/vitrage-tempest-plugin>`__
-openstack/watcher                        `https://opendev.org/openstack/watcher <https://opendev.org/openstack/watcher>`__
-openstack/watcher-dashboard              `https://opendev.org/openstack/watcher-dashboard <https://opendev.org/openstack/watcher-dashboard>`__
-openstack/whitebox-tempest-plugin        `https://opendev.org/openstack/whitebox-tempest-plugin <https://opendev.org/openstack/whitebox-tempest-plugin>`__
-openstack/zaqar                          `https://opendev.org/openstack/zaqar <https://opendev.org/openstack/zaqar>`__
-openstack/zaqar-ui                       `https://opendev.org/openstack/zaqar-ui <https://opendev.org/openstack/zaqar-ui>`__
-openstack/zun                            `https://opendev.org/openstack/zun <https://opendev.org/openstack/zun>`__
-openstack/zun-ui                         `https://opendev.org/openstack/zun-ui <https://opendev.org/openstack/zun-ui>`__
-performa/os-faults                       `https://opendev.org/performa/os-faults <https://opendev.org/performa/os-faults>`__
-starlingx/config                         `https://opendev.org/starlingx/config <https://opendev.org/starlingx/config>`__
-starlingx/fault                          `https://opendev.org/starlingx/fault <https://opendev.org/starlingx/fault>`__
-starlingx/ha                             `https://opendev.org/starlingx/ha <https://opendev.org/starlingx/ha>`__
-starlingx/integ                          `https://opendev.org/starlingx/integ <https://opendev.org/starlingx/integ>`__
-starlingx/metal                          `https://opendev.org/starlingx/metal <https://opendev.org/starlingx/metal>`__
-starlingx/nfv                            `https://opendev.org/starlingx/nfv <https://opendev.org/starlingx/nfv>`__
-starlingx/update                         `https://opendev.org/starlingx/update <https://opendev.org/starlingx/update>`__
-vexxhost/openstack-operator              `https://opendev.org/vexxhost/openstack-operator <https://opendev.org/vexxhost/openstack-operator>`__
-x/almanach                               `https://opendev.org/x/almanach <https://opendev.org/x/almanach>`__
-x/apmec                                  `https://opendev.org/x/apmec <https://opendev.org/x/apmec>`__
-x/bilean                                 `https://opendev.org/x/bilean <https://opendev.org/x/bilean>`__
-x/broadview-collector                    `https://opendev.org/x/broadview-collector <https://opendev.org/x/broadview-collector>`__
-x/collectd-openstack-plugins             `https://opendev.org/x/collectd-openstack-plugins <https://opendev.org/x/collectd-openstack-plugins>`__
-x/devstack-plugin-additional-pkg-repos   `https://opendev.org/x/devstack-plugin-additional-pkg-repos <https://opendev.org/x/devstack-plugin-additional-pkg-repos>`__
-x/devstack-plugin-glusterfs              `https://opendev.org/x/devstack-plugin-glusterfs <https://opendev.org/x/devstack-plugin-glusterfs>`__
-x/devstack-plugin-hdfs                   `https://opendev.org/x/devstack-plugin-hdfs <https://opendev.org/x/devstack-plugin-hdfs>`__
-x/devstack-plugin-libvirt-qemu           `https://opendev.org/x/devstack-plugin-libvirt-qemu <https://opendev.org/x/devstack-plugin-libvirt-qemu>`__
-x/devstack-plugin-mariadb                `https://opendev.org/x/devstack-plugin-mariadb <https://opendev.org/x/devstack-plugin-mariadb>`__
-x/devstack-plugin-tobiko                 `https://opendev.org/x/devstack-plugin-tobiko <https://opendev.org/x/devstack-plugin-tobiko>`__
-x/devstack-plugin-vmax                   `https://opendev.org/x/devstack-plugin-vmax <https://opendev.org/x/devstack-plugin-vmax>`__
-x/drbd-devstack                          `https://opendev.org/x/drbd-devstack <https://opendev.org/x/drbd-devstack>`__
-x/fenix                                  `https://opendev.org/x/fenix <https://opendev.org/x/fenix>`__
-x/gce-api                                `https://opendev.org/x/gce-api <https://opendev.org/x/gce-api>`__
-x/glare                                  `https://opendev.org/x/glare <https://opendev.org/x/glare>`__
-x/group-based-policy                     `https://opendev.org/x/group-based-policy <https://opendev.org/x/group-based-policy>`__
-x/gyan                                   `https://opendev.org/x/gyan <https://opendev.org/x/gyan>`__
-x/horizon-mellanox                       `https://opendev.org/x/horizon-mellanox <https://opendev.org/x/horizon-mellanox>`__
-x/ironic-staging-drivers                 `https://opendev.org/x/ironic-staging-drivers <https://opendev.org/x/ironic-staging-drivers>`__
-x/kingbird                               `https://opendev.org/x/kingbird <https://opendev.org/x/kingbird>`__
-x/meteos                                 `https://opendev.org/x/meteos <https://opendev.org/x/meteos>`__
-x/meteos-ui                              `https://opendev.org/x/meteos-ui <https://opendev.org/x/meteos-ui>`__
-x/mixmatch                               `https://opendev.org/x/mixmatch <https://opendev.org/x/mixmatch>`__
-x/mogan                                  `https://opendev.org/x/mogan <https://opendev.org/x/mogan>`__
-x/mogan-ui                               `https://opendev.org/x/mogan-ui <https://opendev.org/x/mogan-ui>`__
-x/networking-6wind                       `https://opendev.org/x/networking-6wind <https://opendev.org/x/networking-6wind>`__
-x/networking-ansible                     `https://opendev.org/x/networking-ansible <https://opendev.org/x/networking-ansible>`__
-x/networking-arista                      `https://opendev.org/x/networking-arista <https://opendev.org/x/networking-arista>`__
-x/networking-brocade                     `https://opendev.org/x/networking-brocade <https://opendev.org/x/networking-brocade>`__
-x/networking-cisco                       `https://opendev.org/x/networking-cisco <https://opendev.org/x/networking-cisco>`__
-x/networking-cumulus                     `https://opendev.org/x/networking-cumulus <https://opendev.org/x/networking-cumulus>`__
-x/networking-dpm                         `https://opendev.org/x/networking-dpm <https://opendev.org/x/networking-dpm>`__
-x/networking-fortinet                    `https://opendev.org/x/networking-fortinet <https://opendev.org/x/networking-fortinet>`__
-x/networking-hpe                         `https://opendev.org/x/networking-hpe <https://opendev.org/x/networking-hpe>`__
-x/networking-huawei                      `https://opendev.org/x/networking-huawei <https://opendev.org/x/networking-huawei>`__
-x/networking-infoblox                    `https://opendev.org/x/networking-infoblox <https://opendev.org/x/networking-infoblox>`__
-x/networking-l2gw                        `https://opendev.org/x/networking-l2gw <https://opendev.org/x/networking-l2gw>`__
-x/networking-lagopus                     `https://opendev.org/x/networking-lagopus <https://opendev.org/x/networking-lagopus>`__
-x/networking-mlnx                        `https://opendev.org/x/networking-mlnx <https://opendev.org/x/networking-mlnx>`__
-x/networking-nec                         `https://opendev.org/x/networking-nec <https://opendev.org/x/networking-nec>`__
-x/networking-omnipath                    `https://opendev.org/x/networking-omnipath <https://opendev.org/x/networking-omnipath>`__
-x/networking-opencontrail                `https://opendev.org/x/networking-opencontrail <https://opendev.org/x/networking-opencontrail>`__
-x/networking-ovs-dpdk                    `https://opendev.org/x/networking-ovs-dpdk <https://opendev.org/x/networking-ovs-dpdk>`__
-x/networking-plumgrid                    `https://opendev.org/x/networking-plumgrid <https://opendev.org/x/networking-plumgrid>`__
-x/networking-spp                         `https://opendev.org/x/networking-spp <https://opendev.org/x/networking-spp>`__
-x/networking-vpp                         `https://opendev.org/x/networking-vpp <https://opendev.org/x/networking-vpp>`__
-x/networking-vsphere                     `https://opendev.org/x/networking-vsphere <https://opendev.org/x/networking-vsphere>`__
-x/neutron-classifier                     `https://opendev.org/x/neutron-classifier <https://opendev.org/x/neutron-classifier>`__
-x/nova-dpm                               `https://opendev.org/x/nova-dpm <https://opendev.org/x/nova-dpm>`__
-x/nova-mksproxy                          `https://opendev.org/x/nova-mksproxy <https://opendev.org/x/nova-mksproxy>`__
-x/oaktree                                `https://opendev.org/x/oaktree <https://opendev.org/x/oaktree>`__
-x/omni                                   `https://opendev.org/x/omni <https://opendev.org/x/omni>`__
-x/os-xenapi                              `https://opendev.org/x/os-xenapi <https://opendev.org/x/os-xenapi>`__
-x/picasso                                `https://opendev.org/x/picasso <https://opendev.org/x/picasso>`__
-x/rsd-virt-for-nova                      `https://opendev.org/x/rsd-virt-for-nova <https://opendev.org/x/rsd-virt-for-nova>`__
-x/scalpels                               `https://opendev.org/x/scalpels <https://opendev.org/x/scalpels>`__
-x/slogging                               `https://opendev.org/x/slogging <https://opendev.org/x/slogging>`__
-x/stackube                               `https://opendev.org/x/stackube <https://opendev.org/x/stackube>`__
-x/tap-as-a-service-dashboard             `https://opendev.org/x/tap-as-a-service-dashboard <https://opendev.org/x/tap-as-a-service-dashboard>`__
-x/tatu                                   `https://opendev.org/x/tatu <https://opendev.org/x/tatu>`__
-x/trio2o                                 `https://opendev.org/x/trio2o <https://opendev.org/x/trio2o>`__
-x/valet                                  `https://opendev.org/x/valet <https://opendev.org/x/valet>`__
-x/vmware-nsx                             `https://opendev.org/x/vmware-nsx <https://opendev.org/x/vmware-nsx>`__
-x/vmware-vspc                            `https://opendev.org/x/vmware-vspc <https://opendev.org/x/vmware-vspc>`__
-x/whitebox-neutron-tempest-plugin        `https://opendev.org/x/whitebox-neutron-tempest-plugin <https://opendev.org/x/whitebox-neutron-tempest-plugin>`__
-======================================== ===
 
+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]_      |
++----------------+--------------------------------------------------+------------+
+|ironic-inspector|git://git.openstack.org/openstack/ironic-inspector|            |
++----------------+--------------------------------------------------+------------+
+|                |                                                  |            |
++----------------+--------------------------------------------------+------------+
+
+.. [as1] first functional devstack plugin, hence why used in most of
+         the examples.

doc/source/plugins.rst

@@ -12,15 +12,6 @@ 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.
 
-Prerequisites
-=============
-
-If you are planning to create a plugin that is going to host a service in the
-service catalog (that is, your plugin will use the command
-``get_or_create_service``) please make sure that you apply to the `service
-types authority`_ to reserve a valid service-type. This will help to make sure
-that all deployments of your service use the same service-type.
-
 Plugin Interface
 ================
 
@@ -28,16 +19,7 @@ DevStack supports a standard mechanism 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 3 files.
-
-- ``override-defaults`` - a file containing global variables that
-  will be sourced before the lib/* files. This allows the plugin
-  to override the defaults that are otherwise set in the lib/*
-  files.
-
-  For example, override-defaults may export CINDER_ENABLED_BACKENDS
-  to include the plugin-specific storage backend and thus be able
-  to override the default lvm only storage backend for Cinder.
+directory. Inside this directory there can be 2 files.
 
 - ``settings`` - a file containing global variables that will be
   sourced very early in the process. This is helpful if other plugins
@@ -54,34 +36,9 @@ directory. Inside this directory there can be 3 files.
   default value only if the variable is unset or empty; e.g. in bash
   syntax ``FOO=${FOO:-default}``.
 
-  The file should include a ``define_plugin`` line to indicate the
-  plugin's name, which is the name that should be used by users on
-  "enable_plugin" lines.  It should generally be the last component of
-  the git repo path (e.g., if the plugin's repo is
-  openstack/foo, then the name here should be "foo") ::
-
-    define_plugin <YOUR PLUGIN>
-
-  If your plugin depends on another plugin, indicate it in this file
-  with one or more lines like the following::
-
-    plugin_requires <YOUR PLUGIN> <OTHER PLUGIN>
-
-  For a complete example, if the plugin "foo" depends on "bar", the
-  ``settings`` file should include::
-
-    define_plugin foo
-    plugin_requires foo bar
-
-  Devstack does not currently use this dependency information, so it's
-  important that users continue to add enable_plugin lines in the
-  correct order in ``local.conf``, however adding this information
-  allows other tools to consider dependency information when
-  automatically generating ``local.conf`` files.
-
 - ``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 below.
+  internal structure is discussed bellow.
 
 
 Plugins are registered by adding the following to the localrc section
@@ -99,7 +56,7 @@ They are added in the following format::
 
 An example would be as follows::
 
-  enable_plugin ec2-api https://opendev.org/openstack/ec2-api
+  enable_plugin ec2api git://git.openstack.org/stackforge/ec2api
 
 plugin.sh contract
 ==================
@@ -133,8 +90,6 @@ The current full list of ``mode`` and ``phase`` are:
       should exist at this point.
    -  **extra** - Called near the end after layer 1 and 2 services have
       been started.
-   -  **test-config** - Called at the end of devstack used to configure tempest
-      or any other test environments
 
 -  **unstack** - Called by ``unstack.sh`` before other services are shut
    down.
@@ -148,7 +103,7 @@ An example plugin would look something as follows.
 
 ``devstack/settings``::
 
-  # settings file for template
+    # settings file for template
   enable_service template
 
 
@@ -222,62 +177,23 @@ dependency mechanism is beyond the scope of the current work.
 System Packages
 ===============
 
+Devstack provides a framework for getting packages installed at an early
+phase of its execution. These packages may be defined in a plugin as files
+that contain new-line separated lists of packages required by the plugin
 
-
-Devstack based
---------------
-
-Devstack provides a custom framework for getting packages installed at
-an early phase of its execution.  These packages may be defined in a
-plugin as files that contain new-line separated lists of packages
-required by the plugin
-
-Supported packaging systems include apt and yum across multiple
-distributions.  To enable a plugin to hook into this and install
-package dependencies, packages may be listed at the following
-locations in the top-level of the plugin repository:
+Supported packaging systems include apt and yum across multiple distributions.
+To enable a plugin to hook into this and install package dependencies, packages
+may be listed at the following locations in the top-level of the plugin
+repository:
 
 - ``./devstack/files/debs/$plugin_name`` - Packages to install when running
-  on Ubuntu or Debian.
+  on Ubuntu, Debian or Linux Mint.
 
 - ``./devstack/files/rpms/$plugin_name`` - Packages to install when running
-  on Red Hat, Fedora, or CentOS.
+  on Red Hat, Fedora, CentOS or XenServer.
 
-Although there a no plans to remove this method of installing
-packages, plugins should consider it deprecated for ``bindep`` support
-described below.
-
-bindep
-------
-
-The `bindep <https://docs.openstack.org/infra/bindep>`__ project has
-become the defacto standard for OpenStack projects to specify binary
-dependencies.
-
-A plugin may provide a ``./devstack/files/bindep.txt`` file, which
-will be called with the *default* profile to install packages.  For
-details on the syntax, etc. see the bindep documentation.
-
-It is also possible to use the ``bindep.txt`` of projects that are
-being installed from source with the ``-bindep`` flag available in
-install functions.  For example
-
-.. code-block:: bash
-
-  if use_library_from_git "diskimage-builder"; then
-     GITREPO["diskimage-builder"]=$DISKIMAGE_BUILDER_REPO_URL
-     GITDIR["diskimage-builder"]=$DEST/diskimage-builder
-     GITBRANCH["diskimage-builder"]=$DISKIMAGE_BUILDER_REPO_REF
-     git_clone_by_name "diskimage-builder"
-     setup_dev_lib -bindep "diskimage-builder"
-  fi
-
-will result in any packages required by the ``bindep.txt`` of the
-``diskimage-builder`` project being installed.  Note however that jobs
-that switch projects between source and released/pypi installs
-(e.g. with a ``foo-dsvm`` and a ``foo-dsvm-src`` test to cover both
-released dependencies and master versions) will have to deal with
-``bindep.txt`` being unavailable without the source directory.
+- ``./devstack/files/rpms-suse/$plugin_name`` - Packages to install when
+  running on SUSE Linux or openSUSE.
 
 
 Using Plugins in the OpenStack Gate
@@ -286,12 +202,13 @@ 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. This allows testing of the plugin as well as provides network
+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 openstack/ec2-api
+the project they are being tested. For example, the stackforge/ec2-api
 project has its plugin support in its own tree.
 
 However, some times a DevStack plugin might be used solely to
@@ -301,34 +218,25 @@ 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
-``openstack/devstack-plugin-FOO`` project.
-
-Legacy project-config jobs
---------------------------
+``stackforge/devstack-plugin-FOO`` project.
 
 To enable a plugin to be used in a gate job, the following lines will
 be needed in your ``jenkins/jobs/<project>.yaml`` definition in
-`project-config <https://opendev.org/openstack/project-config/>`_::
+`project-config
+<http://git.openstack.org/cgit/openstack-infra/project-config/>`_::
 
   # 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="openstack/ec2-api $PROJECTS"
+  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 https://opendev.org/openstack/ec2-api"
-
-Zuul v3 jobs
-------------
-
-See the ``devstack_plugins`` example in :doc:`zuul_ci_jobs_migration`.
+  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
-:doc:`Plugin Registry <plugin-registry>`.
-
-.. _service types authority: https://specs.openstack.org/openstack/service-types-authority/
+`Plugin Registry <plugin-registry.html>`_.

doc/source/stackrc.rst

@@ -0,0 +1,66 @@
+===========================
+stackrc - DevStack Settings
+===========================
+
+``stackrc`` is the primary configuration file for DevStack. It contains
+all of the settings that control the services started and the
+repositories used to download the source for those services. ``stackrc``
+sources the ``localrc`` section of ``local.conf`` to perform the default
+overrides.
+
+DATABASE\_TYPE
+    Select the database backend to use. The default is ``mysql``,
+    ``postgresql`` is also available.
+ENABLED\_SERVICES
+    Specify which services to launch. These generally correspond to
+    screen tabs. The default includes: Glance (API and Registry),
+    Keystone, Nova (API, Certificate, Object Store, Compute, Network,
+    Scheduler, Certificate Authentication), Cinder
+    (Scheduler, API, Volume), Horizon, MySQL, RabbitMQ, Tempest.
+
+    ::
+
+        ENABLED_SERVICES=g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-net,n-cond,c-sch,c-api,c-vol,n-sch,n-cauth,horizon,rabbit,tempest,$DATABASE_TYPE
+
+    Other services that are not enabled by default can be enabled in
+    ``localrc``. For example, to add Swift, use the following service
+    names:
+
+    ::
+
+        enable_service s-proxy s-object s-container s-account
+
+    A service can similarly be disabled:
+
+    ::
+
+        disable_service horizon
+
+Service Repos
+    The Git repositories used to check out the source for each service
+    are controlled by a pair of variables set for each service.
+    ``*_REPO`` points to the repository and ``*_BRANCH`` selects which
+    branch to check out. These may be overridden in ``local.conf`` to
+    pull source from a different repo for testing, such as a Gerrit
+    branch proposal. ``GIT_BASE`` points to the primary repository
+    server.
+
+    ::
+
+        NOVA_REPO=$GIT_BASE/openstack/nova.git
+        NOVA_BRANCH=master
+
+    To pull a branch directly from Gerrit, get the repo and branch from
+    the Gerrit review page:
+
+    ::
+
+        git fetch https://review.openstack.org/p/openstack/nova refs/changes/50/5050/1 && git checkout FETCH_HEAD
+
+    The repo is the stanza following ``fetch`` and the branch is the
+    stanza following that:
+
+    ::
+
+        NOVA_REPO=https://review.openstack.org/p/openstack/nova
+        NOVA_BRANCH=refs/changes/50/5050/1

doc/source/systemd.rst

@@ -1,222 +0,0 @@
-===========================
- Using Systemd in DevStack
-===========================
-
-By default DevStack is run with all the services as systemd unit
-files. Systemd is now the default init system for nearly every Linux
-distro, and systemd encodes and solves many of the problems related to
-poorly running processes.
-
-Why this instead of screen?
-===========================
-
-The screen model for DevStack was invented when the number of services
-that a DevStack user was going to run was typically < 10. This made
-screen hot keys to jump around very easy. However, the landscape has
-changed (not all services are stoppable in screen as some are under
-Apache, there are typically at least 20 items)
-
-There is also a common developer workflow of changing code in more
-than one service, and needing to restart a bunch of services for that
-to take effect.
-
-Unit Structure
-==============
-
-.. note::
-
-   Originally we actually wanted to do this as user units, however
-   there are issues with running this under non interactive
-   shells. For now, we'll be running as system units. Some user unit
-   code is left in place in case we can switch back later.
-
-All DevStack user units are created as a part of the DevStack slice
-given the name ``devstack@$servicename.service``. This makes it easy
-to understand which services are part of the devstack run, and lets us
-disable / stop them in a single command.
-
-Manipulating Units
-==================
-
-Assuming the unit ``n-cpu`` to make the examples more clear.
-
-Enable a unit (allows it to be started)::
-
-  sudo systemctl enable devstack@n-cpu.service
-
-Disable a unit::
-
-  sudo systemctl disable devstack@n-cpu.service
-
-Start a unit::
-
-  sudo systemctl start devstack@n-cpu.service
-
-Stop a unit::
-
-  sudo systemctl stop devstack@n-cpu.service
-
-Restart a unit::
-
-  sudo systemctl restart devstack@n-cpu.service
-
-See status of a unit::
-
-  sudo systemctl status devstack@n-cpu.service
-
-Operating on more than one unit at a time
------------------------------------------
-
-Systemd supports wildcarding for unit operations. To restart every
-service in devstack you can do that following::
-
-  sudo systemctl restart devstack@*
-
-Or to see the status of all Nova processes you can do::
-
-  sudo systemctl status devstack@n-*
-
-We'll eventually make the unit names a bit more meaningful so that
-it's easier to understand what you are restarting.
-
-.. _journalctl-examples:
-
-Querying Logs
-=============
-
-One of the other major things that comes with systemd is journald, a
-consolidated way to access logs (including querying through structured
-metadata). This is accessed by the user via ``journalctl`` command.
-
-
-Logs can be accessed through ``journalctl``. journalctl has powerful
-query facilities. We'll start with some common options.
-
-Follow logs for a specific service::
-
-  sudo journalctl -f --unit devstack@n-cpu.service
-
-Following logs for multiple services simultaneously::
-
-  sudo journalctl -f --unit devstack@n-cpu.service --unit devstack@n-cond.service
-
-or you can even do wild cards to follow all the nova services::
-
-  sudo journalctl -f --unit devstack@n-*
-
-Use higher precision time stamps::
-
-  sudo journalctl -f -o short-precise --unit devstack@n-cpu.service
-
-By default, journalctl strips out "unprintable" characters, including
-ASCII color codes. To keep the color codes (which can be interpreted by
-an appropriate terminal/pager - e.g. ``less``, the default)::
-
-  sudo journalctl -a --unit devstack@n-cpu.service
-
-When outputting to the terminal using the default pager, long lines
-will be truncated, but horizontal scrolling is supported via the
-left/right arrow keys. You can override this by setting the
-``SYSTEMD_LESS`` environment variable to e.g. ``FRXM``.
-
-You can pipe the output to another tool, such as ``grep``. For
-example, to find a server instance UUID in the nova logs::
-
-  sudo journalctl -a --unit devstack@n-* | grep 58391b5c-036f-44d5-bd68-21d3c26349e6
-
-See ``man 1 journalctl`` for more.
-
-Debugging
-=========
-
-Using pdb
----------
-
-In order to break into a regular pdb session on a systemd-controlled
-service, you need to invoke the process manually - that is, take it out
-of systemd's control.
-
-Discover the command systemd is using to run the service::
-
-  systemctl show devstack@n-sch.service -p ExecStart --no-pager
-
-Stop the systemd service::
-
-  sudo systemctl stop devstack@n-sch.service
-
-Inject your breakpoint in the source, e.g.::
-
-  import pdb; pdb.set_trace()
-
-Invoke the command manually::
-
-  /usr/local/bin/nova-scheduler --config-file /etc/nova/nova.conf
-
-Some executables, such as :program:`nova-compute`, will need to be executed
-with a particular group. This will be shown in the systemd unit file::
-
-  sudo systemctl cat devstack@n-cpu.service | grep Group
-
-::
-
-  Group = libvirt
-
-Use the :program:`sg` tool to execute the command as this group::
-
-  sg libvirt -c '/usr/local/bin/nova-compute --config-file /etc/nova/nova-cpu.conf'
-
-Using remote-pdb
-----------------
-
-`remote-pdb`_ works while the process is under systemd control.
-
-Make sure you have remote-pdb installed::
-
-  sudo pip install remote-pdb
-
-Inject your breakpoint in the source, e.g.::
-
-  import remote_pdb; remote_pdb.set_trace()
-
-Restart the relevant service::
-
-  sudo systemctl restart devstack@n-api.service
-
-The remote-pdb code configures the telnet port when ``set_trace()`` is
-invoked.  Do whatever it takes to hit the instrumented code path, and
-inspect the logs for a message displaying the listening port::
-
-  Sep 07 16:36:12 p8-100-neo devstack@n-api.service[772]: RemotePdb session open at 127.0.0.1:46771, waiting for connection ...
-
-Telnet to that port to enter the pdb session::
-
-  telnet 127.0.0.1 46771
-
-See the `remote-pdb`_ home page for more options.
-
-.. _`remote-pdb`: https://pypi.org/project/remote-pdb/
-
-Future Work
-===========
-
-user units
-----------
-
-It would be great if we could do services as user units, so that there
-is a clear separation of code being run as not root, to ensure running
-as root never accidentally gets baked in as an assumption to
-services. However, user units interact poorly with devstack-gate and
-the way that commands are run as users with ansible and su.
-
-Maybe someday we can figure that out.
-
-References
-==========
-
-- Arch Linux Wiki - https://wiki.archlinux.org/index.php/Systemd/User
-- Python interface to journald -
-  https://www.freedesktop.org/software/systemd/python-systemd/journal.html
-- Systemd documentation on service files -
-  https://www.freedesktop.org/software/systemd/man/systemd.service.html
-- Systemd documentation on exec (can be used to impact service runs) -
-  https://www.freedesktop.org/software/systemd/man/systemd.exec.html

doc/source/tempest.rst

@@ -1,25 +0,0 @@
-=======
-Tempest
-=======
-
-`Tempest`_ is the OpenStack Integration test suite. It is installed by default
-and is used to provide integration testing for many of the OpenStack services.
-Just like DevStack itself, it is possible to extend Tempest with plugins. In
-fact, many Tempest plugin packages also include DevStack plugin to do things
-like pre-create required static resources.
-
-The `Tempest documentation <Tempest>`_ provides a thorough guide to using
-Tempest. However, if you simply wish to run the standard set of Tempest tests
-against an existing deployment, you can do the following:
-
-.. code-block:: shell
-
-    cd /opt/stack/tempest
-    /opt/stack/data/venv/bin/tempest run ...
-
-The above assumes you have installed DevStack in the default location
-(configured via the ``DEST`` configuration variable) and have enabled
-virtualenv-based installation in the standard location (configured via the
-``USE_VENV`` and ``VENV_DEST`` configuration variables, respectively).
-
-.. _Tempest: https://docs.openstack.org/tempest/latest/

doc/source/zuul_ci_jobs_migration.rst

@@ -1,320 +0,0 @@
-===============================
-Migrating Zuul V2 CI jobs to V3
-===============================
-
-The OpenStack CI system moved from Zuul v2 to Zuul v3, and all CI jobs moved to
-the new CI system. All jobs have been migrated automatically to a format
-compatible with Zuul v3; the jobs produced in this way however are suboptimal
-and do not use the capabilities introduced by Zuul v3, which allow for re-use of
-job parts, in the form of Ansible roles, as well as inheritance between jobs.
-
-DevStack hosts a set of roles, plays and jobs that can be used by other
-repositories to define their DevStack based jobs. To benefit from them, jobs
-must be migrated from the legacy v2 ones into v3 native format.
-
-This document provides guidance and examples to make the migration process as
-painless and smooth as possible.
-
-Where to host the job definitions.
-==================================
-
-In Zuul V3 jobs can be defined in the repository that contains the code they
-excercise. If you are writing CI jobs for an OpenStack service you can define
-your DevStack based CI jobs in one of the repositories that host the code for
-your service. If you have a branchless repo, like a Tempest plugin, that is
-a convenient choice to host the job definitions since job changes do not have
-to be backported. For example, see the beginning of the ``.zuul.yaml`` from the
-sahara Tempest plugin repo:
-
-.. code:: yaml
-
-  # In https://opendev.org/openstack/sahara-tests/src/branch/master/.zuul.yaml:
-  - job:
-      name: sahara-tests-tempest
-      description: |
-        Run Tempest tests from the Sahara plugin.
-      parent: devstack-tempest
-
-Which base job to start from
-============================
-
-If your job needs an OpenStack cloud deployed via DevStack, but you don't plan
-on running Tempest tests, you can start from one of the base
-:doc:`jobs <zuul_jobs>` defined in the DevStack repo.
-
-The ``devstack`` job can be used for both single-node jobs and multi-node jobs,
-and it includes the list of services used in the integrated gate (keystone,
-glance, nova, cinder, neutron and swift). Different topologies can be achieved
-by switching the nodeset used in the child job.
-
-The ``devstack-base`` job is similar to ``devstack`` but it does not specify any
-required repo or service to be run in DevStack. It can be useful to setup
-children jobs that use a very narrow DevStack setup.
-
-If your job needs an OpenStack cloud deployed via DevStack, and you do plan
-on running Tempest tests, you can start from one of the base jobs defined in the
-Tempest repo.
-
-The ``devstack-tempest`` job can be used for both single-node jobs and
-multi-node jobs. Different topologies can be achieved by switching the nodeset
-used in the child job.
-
-Jobs can be customized as follows without writing any Ansible code:
-
-- add and/or remove DevStack services
-- add or modify DevStack and services configuration
-- install DevStack plugins
-- extend the number of sub-nodes (multinode only)
-- define extra log files and/or directories to be uploaded on logs.o.o
-- define extra log file extensions to be rewritten to .txt for ease of access
-
-Tempest jobs can be further customized as follows:
-
-- define the Tempest tox environment to be used
-- define the test concurrency
-- define the test regular expression
-
-Writing Ansible code, or importing existing custom roles, jobs can be further
-extended by:
-
-- adding pre and/or post playbooks
-- overriding the run playbook, add custom roles
-
-The (partial) example below extends a Tempest single node base job
-"devstack-tempest" in the Kuryr repository. The parent job name is defined in
-job.parent.
-
-.. code:: yaml
-
-  # https://opendev.org/openstack/kuryr-kubernetes/src/branch/master/.zuul.d/base.yaml:
-  - job:
-      name: kuryr-kubernetes-tempest-base
-      parent: devstack-tempest
-      description: Base kuryr-kubernetes-job
-      required-projects:
-        - openstack/devstack-plugin-container
-        - openstack/kuryr
-        - openstack/kuryr-kubernetes
-        - openstack/kuryr-tempest-plugin
-        - openstack/neutron-lbaas
-      vars:
-        tempest_test_regex: '^(kuryr_tempest_plugin.tests.)'
-        tox_envlist: 'all'
-        devstack_localrc:
-          KURYR_K8S_API_PORT: 8080
-        devstack_services:
-          kubernetes-api: true
-          kubernetes-controller-manager: true
-          kubernetes-scheduler: true
-          kubelet: true
-          kuryr-kubernetes: true
-          (...)
-        devstack_plugins:
-          kuryr-kubernetes: https://opendev.org/openstack/kuryr
-          devstack-plugin-container: https://opendev.org/openstack/devstack-plugin-container
-          neutron-lbaas: https://opendev.org/openstack/neutron-lbaas
-        tempest_plugins:
-          - kuryr-tempest-plugin
-        (...)
-
-Job variables
-=============
-
-Variables can be added to the job in three different places:
-
-- job.vars: these are global variables available to all node in the nodeset
-- job.host-vars.[HOST]: these are variables available only to the specified HOST
-- job.group-vars.[GROUP]: these are variables available only to the specified
-  GROUP
-
-Zuul merges dict variables through job inheritance. Host and group variables
-override variables with the same name defined as global variables.
-
-In the example below, for the sundaes job, hosts that are not part of the
-subnode group will run vanilla and chocolate. Hosts in the subnode group will
-run stracciatella and strawberry.
-
-.. code:: yaml
-
-  - job:
-      name: ice-creams
-      vars:
-        devstack_service:
-          vanilla: true
-          chocolate: false
-      group-vars:
-        subnode:
-          devstack_service:
-            pistacchio: true
-            stracciatella: true
-
-  - job:
-      name: sundaes
-      parent: ice-creams
-      vars:
-        devstack_service:
-          chocolate: true
-      group-vars:
-        subnode:
-          devstack_service:
-            strawberry: true
-            pistacchio: false
-
-
-DevStack Gate Flags
-===================
-
-The old CI system worked using a combination of DevStack, Tempest and
-devstack-gate to setup a test environment and run tests against it. With Zuul
-V3, the logic that used to live in devstack-gate is moved into different repos,
-including DevStack, Tempest and grenade.
-
-DevStack-gate exposes an interface for job definition based on a number of
-DEVSTACK_GATE_* environment variables, or flags. This guide shows how to map
-DEVSTACK_GATE flags into the new
-system.
-
-The repo column indicates in which repository is hosted the code that replaces
-the devstack-gate flag. The new implementation column explains how to reproduce
-the same or a similar behaviour in Zuul v3 jobs. For localrc settings,
-devstack-gate defined a default value. In ansible jobs the default is either the
-value defined in the parent job, or the default from DevStack, if any.
-
-.. list-table:: **DevStack Gate Flags**
-   :widths: 20 10 60
-   :header-rows: 1
-
-   * - DevStack gate flag
-     - Repo
-     - New implementation
-   * - OVERRIDE_ZUUL_BRANCH
-     - zuul
-     - override-checkout: [branch] in the job definition.
-   * - DEVSTACK_GATE_NET_OVERLAY
-     - zuul-jobs
-     - A bridge called br-infra is set up for all jobs that inherit
-       from multinode with a dedicated `bridge role
-       <https://zuul-ci.org/docs/zuul-jobs/general-roles.html#role-multi-node-bridge>`_.
-   * - DEVSTACK_CINDER_VOLUME_CLEAR
-     - devstack
-     - *CINDER_VOLUME_CLEAR: true/false* in devstack_localrc in the
-       job vars.
-   * - DEVSTACK_GATE_NEUTRON
-     - devstack
-     - True by default. To disable, disable all neutron services in
-       devstack_services in the job definition.
-   * - DEVSTACK_GATE_CONFIGDRIVE
-     - devstack
-     - *FORCE_CONFIG_DRIVE: true/false* in devstack_localrc in the job
-       vars.
-   * - DEVSTACK_GATE_INSTALL_TESTONLY
-     - devstack
-     - *INSTALL_TESTONLY_PACKAGES: true/false* in devstack_localrc in
-       the job vars.
-   * - DEVSTACK_GATE_VIRT_DRIVER
-     - devstack
-     - *VIRT_DRIVER: [virt driver]* in devstack_localrc in the job
-       vars.
-   * - DEVSTACK_GATE_LIBVIRT_TYPE
-     - devstack
-     - *LIBVIRT_TYPE: [libvirt type]* in devstack_localrc in the job
-       vars.
-   * - DEVSTACK_GATE_TEMPEST
-     - devstack and tempest
-     - Defined by the job that is used. The ``devstack`` job only runs
-       devstack. The ``devstack-tempest`` one triggers a Tempest run
-       as well.
-   * - DEVSTACK_GATE_TEMPEST_FULL
-     - tempest
-     - *tox_envlist: full* in the job vars.
-   * - DEVSTACK_GATE_TEMPEST_ALL
-     - tempest
-     - *tox_envlist: all* in the job vars.
-   * - DEVSTACK_GATE_TEMPEST_ALL_PLUGINS
-     - tempest
-     - *tox_envlist: all-plugin* in the job vars.
-   * - DEVSTACK_GATE_TEMPEST_SCENARIOS
-     - tempest
-     - *tox_envlist: scenario* in the job vars.
-   * - TEMPEST_CONCURRENCY
-     - tempest
-     - *tempest_concurrency: [value]* in the job vars. This is
-       available only on jobs that inherit from ``devstack-tempest``
-       down.
-   * - DEVSTACK_GATE_TEMPEST_NOTESTS
-     - tempest
-     - *tox_envlist: venv-tempest* in the job vars. This will create
-       Tempest virtual environment but run no tests.
-   * - DEVSTACK_GATE_SMOKE_SERIAL
-     - tempest
-     - *tox_envlist: smoke-serial* in the job vars.
-   * - DEVSTACK_GATE_TEMPEST_DISABLE_TENANT_ISOLATION
-     - tempest
-     - *tox_envlist: full-serial* in the job vars.
-       *TEMPEST_ALLOW_TENANT_ISOLATION: false* in devstack_localrc in
-       the job vars.
-
-
-The following flags have not been migrated yet or are legacy and won't be
-migrated at all.
-
-.. list-table:: **Not Migrated DevStack Gate Flags**
-   :widths: 20 10 60
-   :header-rows: 1
-
-   * - DevStack gate flag
-     - Status
-     - Details
-   * - DEVSTACK_GATE_TOPOLOGY
-     - WIP
-     - The topology depends on the base job that is used and more
-       specifically on the nodeset attached to it. The new job format
-       allows project to define the variables to be passed to every
-       node/node-group that exists in the topology. Named topologies
-       that include the nodeset and the matching variables can be
-       defined in the form of base jobs.
-   * - DEVSTACK_GATE_GRENADE
-     - TBD
-     - Grenade Zuul V3 jobs will be hosted in the grenade repo.
-   * - GRENADE_BASE_BRANCH
-     - TBD
-     - Grenade Zuul V3 jobs will be hosted in the grenade repo.
-   * - DEVSTACK_GATE_NEUTRON_DVR
-     - TBD
-     - Depends on multinode support.
-   * - DEVSTACK_GATE_EXERCISES
-     - TBD
-     - Can be done on request.
-   * - DEVSTACK_GATE_IRONIC
-     - TBD
-     - This will probably be implemented on ironic side.
-   * - DEVSTACK_GATE_IRONIC_DRIVER
-     - TBD
-     - This will probably be implemented on ironic side.
-   * - DEVSTACK_GATE_IRONIC_BUILD_RAMDISK
-     - TBD
-     - This will probably be implemented on ironic side.
-   * - DEVSTACK_GATE_POSTGRES
-     - Legacy
-     - This flag exists in d-g but the only thing that it does is
-       capture postgres logs. This is already supported by the roles
-       in post, so the flag is useless in the new jobs. postgres
-       itself can be enabled via the devstack_service job variable.
-   * - DEVSTACK_GATE_ZEROMQ
-     - Legacy
-     - This has no effect in d-g.
-   * - DEVSTACK_GATE_MQ_DRIVER
-     - Legacy
-     - This has no effect in d-g.
-   * - DEVSTACK_GATE_TEMPEST_STRESS_ARGS
-     - Legacy
-     - Stress is not in Tempest anymore.
-   * - DEVSTACK_GATE_TEMPEST_HEAT_SLOW
-     - Legacy
-     - This is not used anywhere.
-   * - DEVSTACK_GATE_CELLS
-     - Legacy
-     - This has no effect in d-g.
-   * - DEVSTACK_GATE_NOVA_API_METADATA_SPLIT
-     - Legacy
-     - This has no effect in d-g.

doc/source/zuul_jobs.rst

@@ -1,4 +0,0 @@
-Zuul CI Jobs
-============
-
-.. zuul:autojobs::

doc/source/zuul_roles.rst

@@ -1,4 +0,0 @@
-Zuul CI Roles
-=============
-
-.. zuul:autoroles::

driver_certs/cinder_driver_cert.sh

@@ -0,0 +1,106 @@
+#!/usr/bin/env bash
+
+# **cinder_cert.sh**
+
+# This script is a simple wrapper around the tempest volume api tests
+# It requires that you have a working and functional devstack install
+# and that you've enabled your device driver by making the necessary
+# modifications to /etc/cinder/cinder.conf
+
+# This script will refresh your openstack repo's and restart the cinder
+# services to pick up your driver changes.
+# please NOTE; this script assumes your devstack install is functional
+# and includes tempest. A good first step is to make sure you can
+# create volumes on your device before you even try and run this script.
+
+# It also assumes default install location (/opt/stack/xxx)
+# to aid in debug, you should also verify that you've added
+# an output directory for screen logs:
+#
+#     SCREEN_LOGDIR=/opt/stack/screen-logs
+
+set -o pipefail
+
+CERT_DIR=$(cd $(dirname "$0") && pwd)
+TOP_DIR=$(cd $CERT_DIR/..; pwd)
+
+source $TOP_DIR/functions
+source $TOP_DIR/stackrc
+source $TOP_DIR/openrc
+source $TOP_DIR/lib/infra
+source $TOP_DIR/lib/tempest
+source $TOP_DIR/lib/cinder
+
+TEMPFILE=`mktemp`
+RECLONE=True
+
+function log_message {
+    MESSAGE=$1
+    STEP_HEADER=$2
+    if [[ "$STEP_HEADER" = "True" ]]; then
+        echo -e "\n========================================================" | tee -a $TEMPFILE
+    fi
+    echo -e `date +%m/%d/%y/%T:`"${MESSAGE}" | tee -a $TEMPFILE
+    if [[ "$STEP_HEADER" = "True" ]]; then
+        echo -e "========================================================" | tee -a $TEMPFILE
+    fi
+}
+
+if [[ "$OFFLINE" = "True" ]]; then
+    echo "ERROR: Driver cert requires fresh clone/pull from ${CINDER_BRANCH}"
+    echo "       Please set OFFLINE=False and retry."
+    exit 1
+fi
+
+log_message "RUNNING CINDER DRIVER CERTIFICATION CHECK", True
+log_message "Output is being logged to: $TEMPFILE"
+
+cd $CINDER_DIR
+log_message "Cloning to ${CINDER_REPO}...", True
+install_cinder
+
+log_message "Pull a fresh Clone of cinder repo...", True
+git status | tee -a $TEMPFILE
+git log --pretty=oneline -n 1 | tee -a $TEMPFILE
+
+log_message "Gathering copy of cinder.conf file (passwords will be scrubbed)...", True
+cat /etc/cinder/cinder.conf | egrep -v "(^#.*|^$)" | tee -a $TEMPFILE
+sed -i "s/\(.*password.*=\).*$/\1 xxx/i" $TEMPFILE
+log_message "End of cinder.conf.", True
+
+cd $TOP_DIR
+# Verify tempest is installed/enabled
+if ! is_service_enabled tempest; then
+    log_message "ERROR!!! Cert requires tempest in enabled_services!", True
+    log_message"       Please add tempest to enabled_services and retry."
+    exit 1
+fi
+
+cd $TEMPEST_DIR
+install_tempest
+
+log_message "Verify tempest is current....", True
+git status | tee -a $TEMPFILE
+log_message "Check status and get latest commit..."
+git log --pretty=oneline -n 1 | tee -a $TEMPFILE
+
+
+#stop and restart cinder services
+log_message "Restart Cinder services...", True
+stop_cinder
+sleep 1
+start_cinder
+sleep 5
+
+# run tempest api/volume/test_*
+log_message "Run the actual tempest volume tests (./tools/pretty_tox.sh volume)...", True
+./tools/pretty_tox.sh volume 2>&1 | tee -a $TEMPFILE
+if [[ $? = 0 ]]; then
+    log_message "CONGRATULATIONS!!!  Device driver PASSED!", True
+    log_message "Submit output: ($TEMPFILE)"
+    exit 0
+else
+    log_message "SORRY!!!  Device driver FAILED!", True
+    log_message "Check output in $TEMPFILE"
+    exit 1
+fi

eucarc

@@ -0,0 +1,40 @@
+#!/usr/bin/env bash
+#
+# source eucarc [username] [tenantname]
+#
+# Create EC2 credentials for the current user as defined by OS_TENANT_NAME:OS_USERNAME
+# Optionally set the tenant/username via openrc
+
+if [[ -n "$1" ]]; then
+    USERNAME=$1
+fi
+if [[ -n "$2" ]]; then
+    TENANT=$2
+fi
+
+# Find the other rc files
+RC_DIR=$(cd $(dirname "${BASH_SOURCE:-$0}") && pwd)
+
+# Get user configuration
+source $RC_DIR/openrc
+
+# Set the ec2 url so euca2ools works
+export EC2_URL=$(openstack catalog show ec2 | awk '/ publicURL: / { print $4 }')
+
+# Create EC2 credentials for the current user
+CREDS=$(openstack ec2 credentials create)
+export EC2_ACCESS_KEY=$(echo "$CREDS" | awk '/ access / { print $4 }')
+export EC2_SECRET_KEY=$(echo "$CREDS" | awk '/ secret / { print $4 }')
+
+# Euca2ools Certificate stuff for uploading bundles
+# See exercises/bundle.sh to see how to get certs using nova cli
+NOVA_KEY_DIR=${NOVA_KEY_DIR:-$RC_DIR}
+export S3_URL=$(openstack catalog show s3 | awk '/ publicURL: / { print $4 }')
+export EC2_USER_ID=42 # nova does not use user id, but bundling requires it
+export EC2_PRIVATE_KEY=${NOVA_KEY_DIR}/pk.pem
+export EC2_CERT=${NOVA_KEY_DIR}/cert.pem
+export NOVA_CERT=${NOVA_KEY_DIR}/cacert.pem
+export EUCALYPTUS_CERT=${NOVA_CERT} # euca-bundle-image seems to require this set
+alias ec2-bundle-image="ec2-bundle-image --cert ${EC2_CERT} --privatekey ${EC2_PRIVATE_KEY} --user ${EC2_USER_ID} --ec2cert ${NOVA_CERT}"
+alias ec2-upload-bundle="ec2-upload-bundle -a ${EC2_ACCESS_KEY} -s ${EC2_SECRET_KEY} --url ${S3_URL} --ec2cert ${NOVA_CERT}"
+

exercise.sh

@@ -0,0 +1,74 @@
+#!/usr/bin/env bash
+
+# **exercise.sh**
+
+# Keep track of the current DevStack directory.
+TOP_DIR=$(cd $(dirname "$0") && pwd)
+
+# Import common functions
+source $TOP_DIR/functions
+
+# Load local configuration
+source $TOP_DIR/stackrc
+
+# Run everything in the exercises/ directory that isn't explicitly disabled
+
+# comma separated list of script basenames to skip
+# to refrain from exercising euca.sh use ``SKIP_EXERCISES=euca``
+SKIP_EXERCISES=${SKIP_EXERCISES:-""}
+
+# comma separated list of script basenames to run
+# to run only euca.sh use ``RUN_EXERCISES=euca``
+basenames=${RUN_EXERCISES:-""}
+
+EXERCISE_DIR=$TOP_DIR/exercises
+
+if [[ -z "${basenames}" ]]; then
+    # Locate the scripts we should run
+    basenames=$(for b in `ls $EXERCISE_DIR/*.sh`; do basename $b .sh; done)
+else
+    # If ``RUN_EXERCISES`` was specified, ignore ``SKIP_EXERCISES``.
+    SKIP_EXERCISES=
+fi
+
+# Track the state of each script
+passes=""
+failures=""
+skips=""
+
+# Loop over each possible script (by basename)
+for script in $basenames; do
+    if [[ ,$SKIP_EXERCISES, =~ ,$script, ]]; then
+        skips="$skips $script"
+    else
+        echo "====================================================================="
+        echo Running $script
+        echo "====================================================================="
+        $EXERCISE_DIR/$script.sh
+        exitcode=$?
+        if [[ $exitcode == 55 ]]; then
+            skips="$skips $script"
+        elif [[ $exitcode -ne 0 ]]; then
+            failures="$failures $script"
+        else
+            passes="$passes $script"
+        fi
+    fi
+done
+
+# Output status of exercise run
+echo "====================================================================="
+for script in $skips; do
+    echo SKIP $script
+done
+for script in $passes; do
+    echo PASS $script
+done
+for script in $failures; do
+    echo FAILED $script
+done
+echo "====================================================================="
+
+if [[ -n "$failures" ]]; then
+    exit 1
+fi

exerciserc

@@ -0,0 +1,32 @@
+#!/usr/bin/env bash
+#
+# source exerciserc
+#
+# Configure the DevStack exercise scripts
+# For best results, source this _after_ stackrc/localrc as it will set
+# values only if they are not already set.
+
+# Max time to wait while vm goes from build to active state
+export ACTIVE_TIMEOUT=${ACTIVE_TIMEOUT:-30}
+
+# Max time to wait for proper IP association and dis-association.
+export ASSOCIATE_TIMEOUT=${ASSOCIATE_TIMEOUT:-15}
+
+# Max time till the vm is bootable
+export BOOT_TIMEOUT=${BOOT_TIMEOUT:-30}
+
+# Max time from run instance command until it is running
+export RUNNING_TIMEOUT=${RUNNING_TIMEOUT:-$(($BOOT_TIMEOUT + $ACTIVE_TIMEOUT))}
+
+# Max time to wait for a vm to terminate
+export TERMINATE_TIMEOUT=${TERMINATE_TIMEOUT:-30}
+
+# Max time to wait for a euca-volume command to propagate
+export VOLUME_TIMEOUT=${VOLUME_TIMEOUT:-30}
+
+# Max time to wait for a euca-delete command to propagate
+export VOLUME_DELETE_TIMEOUT=${SNAPSHOT_DELETE_TIMEOUT:-60}
+
+# The size of the volume we want to boot from; some storage back-ends
+# do not allow a disk resize, so it's important that this can be tuned
+export DEFAULT_VOLUME_SIZE=${DEFAULT_VOLUME_SIZE:-1}

exercises/aggregates.sh

@@ -0,0 +1,150 @@
+#!/usr/bin/env bash
+
+# **aggregates.sh**
+
+# This script demonstrates how to use host aggregates:
+#
+# *  Create an Aggregate
+# *  Updating Aggregate details
+# *  Testing Aggregate metadata
+# *  Testing Aggregate delete
+# *  Testing General Aggregates (https://blueprints.launchpad.net/nova/+spec/general-host-aggregates)
+# *  Testing add/remove hosts (with one host)
+
+echo "**************************************************"
+echo "Begin DevStack Exercise: $0"
+echo "**************************************************"
+
+# This script exits on an error so that errors don't compound and you see
+# only the first error that occurred.
+set -o errexit
+
+# Print the commands being run so that we can see the command that triggers
+# an error.  It is also useful for following allowing as the install occurs.
+set -o xtrace
+
+
+# Settings
+# ========
+
+# Keep track of the current directory
+EXERCISE_DIR=$(cd $(dirname "$0") && pwd)
+TOP_DIR=$(cd $EXERCISE_DIR/..; pwd)
+
+# Test as the admin user
+# note this imports stackrc/functions, etc
+. $TOP_DIR/openrc admin admin
+
+# Import exercise configuration
+source $TOP_DIR/exerciserc
+
+# If nova api is not enabled we exit with exitcode 55 so that
+# the exercise is skipped
+is_service_enabled n-api || exit 55
+
+# Cells does not support aggregates.
+is_service_enabled n-cell && exit 55
+
+# Create an aggregate
+# ===================
+
+AGGREGATE_NAME=test_aggregate_$RANDOM
+AGGREGATE2_NAME=test_aggregate_$RANDOM
+AGGREGATE_A_ZONE=nova
+
+function exit_if_aggregate_present {
+    aggregate_name=$1
+
+    if [ $(nova aggregate-list | grep -c " $aggregate_name ") == 0 ]; then
+        echo "SUCCESS $aggregate_name not present"
+    else
+        die $LINENO "found aggregate: $aggregate_name"
+        exit -1
+    fi
+}
+
+exit_if_aggregate_present $AGGREGATE_NAME
+
+AGGREGATE_ID=$(nova aggregate-create $AGGREGATE_NAME $AGGREGATE_A_ZONE | grep " $AGGREGATE_NAME " | get_field 1)
+die_if_not_set $LINENO AGGREGATE_ID "Failure creating AGGREGATE_ID for $AGGREGATE_NAME $AGGREGATE_A_ZONE"
+
+AGGREGATE2_ID=$(nova aggregate-create $AGGREGATE2_NAME $AGGREGATE_A_ZONE | grep " $AGGREGATE2_NAME " | get_field 1)
+die_if_not_set $LINENO AGGREGATE2_ID "Fail creating AGGREGATE2_ID for $AGGREGATE2_NAME $AGGREGATE_A_ZONE"
+
+# check aggregate created
+nova aggregate-list | grep -q " $AGGREGATE_NAME " || die $LINENO "Aggregate $AGGREGATE_NAME not created"
+
+
+# Ensure creating a duplicate fails
+# =================================
+
+if nova aggregate-create $AGGREGATE_NAME $AGGREGATE_A_ZONE; then
+    die $LINENO "could create duplicate aggregate"
+fi
+
+
+# Test aggregate-update (and aggregate-details)
+# =============================================
+AGGREGATE_NEW_NAME=test_aggregate_$RANDOM
+
+nova aggregate-update $AGGREGATE_ID $AGGREGATE_NEW_NAME
+nova aggregate-details $AGGREGATE_ID | grep $AGGREGATE_NEW_NAME
+nova aggregate-details $AGGREGATE_ID | grep $AGGREGATE_A_ZONE
+
+nova aggregate-update $AGGREGATE_ID $AGGREGATE_NAME $AGGREGATE_A_ZONE
+nova aggregate-details $AGGREGATE_ID | grep $AGGREGATE_NAME
+nova aggregate-details $AGGREGATE_ID | grep $AGGREGATE_A_ZONE
+
+
+# Test aggregate-set-metadata
+# ===========================
+META_DATA_1_KEY=asdf
+META_DATA_2_KEY=foo
+META_DATA_3_KEY=bar
+
+#ensure no additional metadata is set
+nova aggregate-details $AGGREGATE_ID | egrep "\|[{u ]*'availability_zone.+$AGGREGATE_A_ZONE'[ }]*\|"
+
+nova aggregate-set-metadata $AGGREGATE_ID ${META_DATA_1_KEY}=123
+nova aggregate-details $AGGREGATE_ID | grep $META_DATA_1_KEY
+nova aggregate-details $AGGREGATE_ID | grep 123
+
+nova aggregate-set-metadata $AGGREGATE_ID ${META_DATA_2_KEY}=456
+nova aggregate-details $AGGREGATE_ID | grep $META_DATA_1_KEY
+nova aggregate-details $AGGREGATE_ID | grep $META_DATA_2_KEY
+
+nova aggregate-set-metadata $AGGREGATE_ID $META_DATA_2_KEY ${META_DATA_3_KEY}=789
+nova aggregate-details $AGGREGATE_ID | grep $META_DATA_1_KEY
+nova aggregate-details $AGGREGATE_ID | grep $META_DATA_3_KEY
+
+nova aggregate-details $AGGREGATE_ID | grep $META_DATA_2_KEY && die $LINENO "ERROR metadata was not cleared"
+
+nova aggregate-set-metadata $AGGREGATE_ID $META_DATA_3_KEY $META_DATA_1_KEY
+nova aggregate-details $AGGREGATE_ID | egrep "\|[{u ]*'availability_zone.+$AGGREGATE_A_ZONE'[ }]*\|"
+
+
+# Test aggregate-add/remove-host
+# ==============================
+if [ "$VIRT_DRIVER" == "xenserver" ]; then
+    echo "TODO(johngarbutt) add tests for add/remove host from pool aggregate"
+fi
+FIRST_HOST=$(nova host-list | grep compute | get_field 1 | head -1)
+# Make sure can add two aggregates to same host
+nova aggregate-add-host $AGGREGATE_ID $FIRST_HOST
+nova aggregate-add-host $AGGREGATE2_ID $FIRST_HOST
+if nova aggregate-add-host $AGGREGATE2_ID $FIRST_HOST; then
+    die $LINENO "could add duplicate host to single aggregate"
+fi
+nova aggregate-remove-host $AGGREGATE2_ID $FIRST_HOST
+nova aggregate-remove-host $AGGREGATE_ID $FIRST_HOST
+
+# Test aggregate-delete
+# =====================
+nova aggregate-delete $AGGREGATE_ID
+nova aggregate-delete $AGGREGATE2_ID
+exit_if_aggregate_present $AGGREGATE_NAME
+
+set +o xtrace
+echo "**************************************************"
+echo "End DevStack Exercise: $0"
+echo "**************************************************"

exercises/boot_from_volume.sh

@@ -0,0 +1,223 @@
+#!/usr/bin/env bash
+
+# **boot_from_volume.sh**
+
+# This script demonstrates how to boot from a volume.  It does the following:
+#
+# *  Create a bootable volume
+# *  Boot a volume-backed instance
+
+echo "*********************************************************************"
+echo "Begin DevStack Exercise: $0"
+echo "*********************************************************************"
+
+# This script exits on an error so that errors don't compound and you see
+# only the first error that occurred.
+set -o errexit
+
+# Print the commands being run so that we can see the command that triggers
+# an error.  It is also useful for following allowing as the install occurs.
+set -o xtrace
+
+
+# Settings
+# ========
+
+# Keep track of the current directory
+EXERCISE_DIR=$(cd $(dirname "$0") && pwd)
+TOP_DIR=$(cd $EXERCISE_DIR/..; pwd)
+
+# Import common functions
+source $TOP_DIR/functions
+
+# Import project functions
+source $TOP_DIR/lib/cinder
+source $TOP_DIR/lib/neutron-legacy
+
+# Import configuration
+source $TOP_DIR/openrc
+
+# Import exercise configuration
+source $TOP_DIR/exerciserc
+
+# If cinder is not enabled we exit with exitcode 55 so that
+# the exercise is skipped
+is_service_enabled cinder || exit 55
+
+# Ironic does not support boot from volume.
+[ "$VIRT_DRIVER" == "ironic" ] && exit 55
+
+# Instance type to create
+DEFAULT_INSTANCE_TYPE=${DEFAULT_INSTANCE_TYPE:-m1.tiny}
+
+# Boot this image, use first AMI image if unset
+DEFAULT_IMAGE_NAME=${DEFAULT_IMAGE_NAME:-ami}
+
+# Security group name
+SECGROUP=${SECGROUP:-boot_secgroup}
+
+# Instance and volume names
+VM_NAME=${VM_NAME:-ex-bfv-inst}
+VOL_NAME=${VOL_NAME:-ex-vol-bfv}
+
+
+# Launching a server
+# ==================
+
+# List servers for tenant:
+nova list
+
+# Images
+# ------
+
+# List the images available
+openstack image list
+
+# Grab the id of the image to launch
+IMAGE=$(openstack image list | egrep " $DEFAULT_IMAGE_NAME " | get_field 1)
+die_if_not_set $LINENO IMAGE "Failure getting image $DEFAULT_IMAGE_NAME"
+
+# Security Groups
+# ---------------
+
+# List security groups
+nova secgroup-list
+
+if is_service_enabled n-cell; then
+    # Cells does not support security groups, so force the use of "default"
+    SECGROUP="default"
+    echo "Using the default security group because of Cells."
+else
+    # Create a secgroup
+    if ! nova secgroup-list | grep -q $SECGROUP; then
+        nova secgroup-create $SECGROUP "$SECGROUP description"
+        if ! timeout $ASSOCIATE_TIMEOUT sh -c "while ! nova secgroup-list | grep -q $SECGROUP; do sleep 1; done"; then
+            echo "Security group not created"
+            exit 1
+        fi
+    fi
+fi
+
+# Configure Security Group Rules
+if ! nova secgroup-list-rules $SECGROUP | grep -q icmp; then
+    nova secgroup-add-rule $SECGROUP icmp -1 -1 0.0.0.0/0
+fi
+if ! nova secgroup-list-rules $SECGROUP | grep -q " tcp .* 22 "; then
+    nova secgroup-add-rule $SECGROUP tcp 22 22 0.0.0.0/0
+fi
+
+# List secgroup rules
+nova secgroup-list-rules $SECGROUP
+
+# Set up instance
+# ---------------
+
+# List flavors
+nova flavor-list
+
+# Select a flavor
+INSTANCE_TYPE=$(nova flavor-list | grep $DEFAULT_INSTANCE_TYPE | get_field 1)
+if [[ -z "$INSTANCE_TYPE" ]]; then
+    # grab the first flavor in the list to launch if default doesn't exist
+    INSTANCE_TYPE=$(nova flavor-list | head -n 4 | tail -n 1 | get_field 1)
+fi
+
+# Clean-up from previous runs
+nova delete $VM_NAME || true
+if ! timeout $ACTIVE_TIMEOUT sh -c "while nova show $VM_NAME; do sleep 1; done"; then
+    echo "server didn't terminate!"
+    exit 1
+fi
+
+# Setup Keypair
+KEY_NAME=test_key
+KEY_FILE=key.pem
+nova keypair-delete $KEY_NAME || true
+nova keypair-add $KEY_NAME > $KEY_FILE
+chmod 600 $KEY_FILE
+
+# Set up volume
+# -------------
+
+# Delete any old volume
+cinder delete $VOL_NAME || true
+if ! timeout $ACTIVE_TIMEOUT sh -c "while cinder list | grep $VOL_NAME; do sleep 1; done"; then
+    echo "Volume $VOL_NAME not deleted"
+    exit 1
+fi
+
+# Create the bootable volume
+start_time=$(date +%s)
+cinder create --image-id $IMAGE --display-name=$VOL_NAME --display-description "test bootable volume: $VOL_NAME" $DEFAULT_VOLUME_SIZE || \
+    die $LINENO "Failure creating volume $VOL_NAME"
+if ! timeout $ACTIVE_TIMEOUT sh -c "while ! cinder list | grep $VOL_NAME | grep available; do sleep 1; done"; then
+    echo "Volume $VOL_NAME not created"
+    exit 1
+fi
+end_time=$(date +%s)
+echo "Completed cinder create in $((end_time - start_time)) seconds"
+
+# Get volume ID
+VOL_ID=$(cinder list | grep $VOL_NAME  | get_field 1)
+die_if_not_set $LINENO VOL_ID "Failure retrieving volume ID for $VOL_NAME"
+
+# Boot instance
+# -------------
+
+# Boot using the --block-device-mapping param. The format of mapping is:
+# <dev_name>=<id>:<type>:<size(GB)>:<delete_on_terminate>
+# Leaving the middle two fields blank appears to do-the-right-thing
+VM_UUID=$(nova boot --flavor $INSTANCE_TYPE --image $IMAGE --block-device-mapping vda=$VOL_ID --security-groups=$SECGROUP --key-name $KEY_NAME $VM_NAME | grep ' id ' | get_field 2)
+die_if_not_set $LINENO VM_UUID "Failure launching $VM_NAME"
+
+# Check that the status is active within ACTIVE_TIMEOUT seconds
+if ! timeout $ACTIVE_TIMEOUT sh -c "while ! nova show $VM_UUID | grep status | grep -q ACTIVE; do sleep 1; done"; then
+    echo "server didn't become active!"
+    exit 1
+fi
+
+# Get the instance IP
+IP=$(get_instance_ip $VM_UUID $PRIVATE_NETWORK_NAME)
+
+die_if_not_set $LINENO IP "Failure retrieving IP address"
+
+# Private IPs can be pinged in single node deployments
+ping_check $IP $BOOT_TIMEOUT "$PRIVATE_NETWORK_NAME"
+
+# Clean up
+# --------
+
+# Delete volume backed instance
+nova delete $VM_UUID || die $LINENO "Failure deleting instance $VM_NAME"
+if ! timeout $TERMINATE_TIMEOUT sh -c "while nova list | grep -q $VM_UUID; do sleep 1; done"; then
+    echo "Server $VM_NAME not deleted"
+    exit 1
+fi
+
+# Wait for volume to be released
+if ! timeout $ACTIVE_TIMEOUT sh -c "while ! cinder list | grep $VOL_NAME | grep available; do sleep 1; done"; then
+    echo "Volume $VOL_NAME not released"
+    exit 1
+fi
+
+# Delete volume
+start_time=$(date +%s)
+cinder delete $VOL_ID || die $LINENO "Failure deleting volume $VOLUME_NAME"
+if ! timeout $ACTIVE_TIMEOUT sh -c "while cinder list | grep $VOL_NAME; do sleep 1; done"; then
+    echo "Volume $VOL_NAME not deleted"
+    exit 1
+fi
+end_time=$(date +%s)
+echo "Completed cinder delete in $((end_time - start_time)) seconds"
+
+if [[ $SECGROUP = "default" ]] ; then
+    echo "Skipping deleting default security group"
+else
+    # Delete secgroup
+    nova secgroup-delete $SECGROUP || die $LINENO "Failure deleting security group $SECGROUP"
+fi
+
+set +o xtrace
+echo "*********************************************************************"
+echo "SUCCESS: End DevStack Exercise: $0"
+echo "*********************************************************************"

exercises/bundle.sh

@@ -0,0 +1,74 @@
+#!/usr/bin/env bash
+
+# **bundle.sh**
+
+# we will use the ``euca2ools`` cli tool that wraps the python boto
+# library to test ec2 bundle upload compatibility
+
+echo "*********************************************************************"
+echo "Begin DevStack Exercise: $0"
+echo "*********************************************************************"
+
+# This script exits on an error so that errors don't compound and you see
+# only the first error that occurred.
+set -o errexit
+
+# Print the commands being run so that we can see the command that triggers
+# an error.  It is also useful for following allowing as the install occurs.
+set -o xtrace
+
+
+# Settings
+# ========
+
+# Keep track of the current directory
+EXERCISE_DIR=$(cd $(dirname "$0") && pwd)
+TOP_DIR=$(cd $EXERCISE_DIR/..; pwd)
+
+# Import common functions
+source $TOP_DIR/functions
+
+# Import EC2 configuration
+source $TOP_DIR/eucarc
+
+# Import exercise configuration
+source $TOP_DIR/exerciserc
+
+# Remove old certificates
+rm -f $TOP_DIR/cacert.pem
+rm -f $TOP_DIR/cert.pem
+rm -f $TOP_DIR/pk.pem
+
+# If nova api is not enabled we exit with exitcode 55 so that
+# the exercise is skipped
+is_service_enabled n-api || exit 55
+
+# Get Certificates
+nova x509-get-root-cert $TOP_DIR/cacert.pem
+nova x509-create-cert $TOP_DIR/pk.pem $TOP_DIR/cert.pem
+
+# Max time to wait for image to be registered
+REGISTER_TIMEOUT=${REGISTER_TIMEOUT:-15}
+
+BUCKET=testbucket
+IMAGE=bundle.img
+truncate -s 5M /tmp/$IMAGE
+euca-bundle-image -i /tmp/$IMAGE || die $LINENO "Failure bundling image $IMAGE"
+
+euca-upload-bundle --debug -b $BUCKET -m /tmp/$IMAGE.manifest.xml || die $LINENO "Failure uploading bundle $IMAGE to $BUCKET"
+
+AMI=`euca-register $BUCKET/$IMAGE.manifest.xml | cut -f2`
+die_if_not_set $LINENO AMI "Failure registering $BUCKET/$IMAGE"
+
+# Wait for the image to become available
+if ! timeout $REGISTER_TIMEOUT sh -c "while euca-describe-images | grep $AMI | grep -q available; do sleep 1; done"; then
+    die $LINENO "Image $AMI not available within $REGISTER_TIMEOUT seconds"
+fi
+
+# Clean up
+euca-deregister $AMI || die $LINENO "Failure deregistering $AMI"
+
+set +o xtrace
+echo "*********************************************************************"
+echo "SUCCESS: End DevStack Exercise: $0"
+echo "*********************************************************************"

exercises/client-args.sh

@@ -0,0 +1,176 @@
+#!/usr/bin/env bash
+
+# **client-args.sh**
+
+# Test OpenStack client authentication arguments handling
+
+echo "*********************************************************************"
+echo "Begin DevStack Exercise: $0"
+echo "*********************************************************************"
+
+# This script exits on an error so that errors don't compound and you see
+# only the first error that occurred.
+set -o errexit
+
+# Print the commands being run so that we can see the command that triggers
+# an error.  It is also useful for following allowing as the install occurs.
+set -o xtrace
+
+
+# Settings
+# ========
+
+# Keep track of the current directory
+EXERCISE_DIR=$(cd $(dirname "$0") && pwd)
+TOP_DIR=$(cd $EXERCISE_DIR/..; pwd)
+
+# Import common functions
+source $TOP_DIR/functions
+
+# Import configuration
+source $TOP_DIR/openrc
+
+# Import exercise configuration
+source $TOP_DIR/exerciserc
+
+# Unset all of the known NOVA_* vars
+unset NOVA_API_KEY
+unset NOVA_ENDPOINT_NAME
+unset NOVA_PASSWORD
+unset NOVA_PROJECT_ID
+unset NOVA_REGION_NAME
+unset NOVA_URL
+unset NOVA_USERNAME
+unset NOVA_VERSION
+
+# Save the known variables for later
+export x_TENANT_NAME=$OS_TENANT_NAME
+export x_USERNAME=$OS_USERNAME
+export x_PASSWORD=$OS_PASSWORD
+export x_AUTH_URL=$OS_AUTH_URL
+
+# Unset the usual variables to force argument processing
+unset OS_TENANT_NAME
+unset OS_USERNAME
+unset OS_PASSWORD
+unset OS_AUTH_URL
+
+# Common authentication args
+TENANT_ARG="--os-tenant-name=$x_TENANT_NAME"
+ARGS="--os-username=$x_USERNAME --os-password=$x_PASSWORD --os-auth-url=$x_AUTH_URL"
+
+# Set global return
+RETURN=0
+
+# Keystone client
+# ---------------
+if [[ "$ENABLED_SERVICES" =~ "key" ]]; then
+    if [[ "$SKIP_EXERCISES" =~ "key" ]]; then
+        STATUS_KEYSTONE="Skipped"
+    else
+        echo -e "\nTest Keystone"
+        if openstack $TENANT_ARG $ARGS catalog show identity; then
+            STATUS_KEYSTONE="Succeeded"
+        else
+            STATUS_KEYSTONE="Failed"
+            RETURN=1
+        fi
+    fi
+fi
+
+# Nova client
+# -----------
+
+if [[ "$ENABLED_SERVICES" =~ "n-api" ]]; then
+    if [[ "$SKIP_EXERCISES" =~ "n-api" ]]; then
+        STATUS_NOVA="Skipped"
+        STATUS_EC2="Skipped"
+    else
+        # Test OSAPI
+        echo -e "\nTest Nova"
+        if nova $TENANT_ARG $ARGS flavor-list; then
+            STATUS_NOVA="Succeeded"
+        else
+            STATUS_NOVA="Failed"
+            RETURN=1
+        fi
+    fi
+fi
+
+# Cinder client
+# -------------
+
+if [[ "$ENABLED_SERVICES" =~ "c-api" ]]; then
+    if [[ "$SKIP_EXERCISES" =~ "c-api" ]]; then
+        STATUS_CINDER="Skipped"
+    else
+        echo -e "\nTest Cinder"
+        if cinder $TENANT_ARG $ARGS list; then
+            STATUS_CINDER="Succeeded"
+        else
+            STATUS_CINDER="Failed"
+            RETURN=1
+        fi
+    fi
+fi
+
+# Glance client
+# -------------
+
+if [[ "$ENABLED_SERVICES" =~ "g-api" ]]; then
+    if [[ "$SKIP_EXERCISES" =~ "g-api" ]]; then
+        STATUS_GLANCE="Skipped"
+    else
+        echo -e "\nTest Glance"
+        if openstack $TENANT_ARG $ARGS image list; then
+            STATUS_GLANCE="Succeeded"
+        else
+            STATUS_GLANCE="Failed"
+            RETURN=1
+        fi
+    fi
+fi
+
+# Swift client
+# ------------
+
+if [[ "$ENABLED_SERVICES" =~ "swift" || "$ENABLED_SERVICES" =~ "s-proxy" ]]; then
+    if [[ "$SKIP_EXERCISES" =~ "swift" ]]; then
+        STATUS_SWIFT="Skipped"
+    else
+        echo -e "\nTest Swift"
+        if swift $TENANT_ARG $ARGS stat; then
+            STATUS_SWIFT="Succeeded"
+        else
+            STATUS_SWIFT="Failed"
+            RETURN=1
+        fi
+    fi
+fi
+
+set +o xtrace
+
+
+# Results
+# =======
+
+function report {
+    if [[ -n "$2" ]]; then
+        echo "$1: $2"
+    fi
+}
+
+echo -e "\n"
+report "Keystone" $STATUS_KEYSTONE
+report "Nova" $STATUS_NOVA
+report "Cinder" $STATUS_CINDER
+report "Glance" $STATUS_GLANCE
+report "Swift" $STATUS_SWIFT
+
+if (( $RETURN == 0 )); then
+    echo "*********************************************************************"
+    echo "SUCCESS: End DevStack Exercise: $0"
+    echo "*********************************************************************"
+fi
+
+exit $RETURN

exercises/client-env.sh

@@ -0,0 +1,188 @@
+#!/usr/bin/env bash
+
+# **client-env.sh**
+
+# Test OpenStack client environment variable handling
+
+echo "*********************************************************************"
+echo "Begin DevStack Exercise: $0"
+echo "*********************************************************************"
+
+# This script exits on an error so that errors don't compound and you see
+# only the first error that occurred.
+set -o errexit
+
+# Print the commands being run so that we can see the command that triggers
+# an error.  It is also useful for following allowing as the install occurs.
+set -o xtrace
+
+
+# Settings
+# ========
+
+# Keep track of the current directory
+EXERCISE_DIR=$(cd $(dirname "$0") && pwd)
+TOP_DIR=$(cd $EXERCISE_DIR/..; pwd)
+
+# Import common functions
+source $TOP_DIR/functions
+
+# Import configuration
+source $TOP_DIR/openrc admin
+
+# Import exercise configuration
+source $TOP_DIR/exerciserc
+
+# Unset all of the known NOVA_* vars
+unset NOVA_API_KEY
+unset NOVA_ENDPOINT_NAME
+unset NOVA_PASSWORD
+unset NOVA_PROJECT_ID
+unset NOVA_REGION_NAME
+unset NOVA_URL
+unset NOVA_USERNAME
+unset NOVA_VERSION
+
+for i in OS_TENANT_NAME OS_USERNAME OS_PASSWORD OS_AUTH_URL; do
+    is_set $i
+    if [[ $? -ne 0 ]]; then
+        echo "$i expected to be set"
+        ABORT=1
+    fi
+done
+if [[ -n "$ABORT" ]]; then
+    exit 1
+fi
+
+# Set global return
+RETURN=0
+
+# Keystone client
+# ---------------
+if [[ "$ENABLED_SERVICES" =~ "key" ]]; then
+    if [[ "$SKIP_EXERCISES" =~ "key" ]]; then
+        STATUS_KEYSTONE="Skipped"
+    else
+        echo -e "\nTest Keystone"
+        if openstack endpoint show identity; then
+            STATUS_KEYSTONE="Succeeded"
+        else
+            STATUS_KEYSTONE="Failed"
+            RETURN=1
+        fi
+    fi
+fi
+
+# Nova client
+# -----------
+
+if [[ "$ENABLED_SERVICES" =~ "n-api" ]]; then
+    if [[ "$SKIP_EXERCISES" =~ "n-api" ]]; then
+        STATUS_NOVA="Skipped"
+        STATUS_EC2="Skipped"
+    else
+        # Test OSAPI
+        echo -e "\nTest Nova"
+        if nova flavor-list; then
+            STATUS_NOVA="Succeeded"
+        else
+            STATUS_NOVA="Failed"
+            RETURN=1
+        fi
+
+        # Test EC2 API
+        echo -e "\nTest EC2"
+        # Get EC2 creds
+        source $TOP_DIR/eucarc
+
+        if euca-describe-images; then
+            STATUS_EC2="Succeeded"
+        else
+            STATUS_EC2="Failed"
+            RETURN=1
+        fi
+
+        # Clean up side effects
+        unset NOVA_VERSION
+    fi
+fi
+
+# Cinder client
+# -------------
+
+if [[ "$ENABLED_SERVICES" =~ "c-api" ]]; then
+    if [[ "$SKIP_EXERCISES" =~ "c-api" ]]; then
+        STATUS_CINDER="Skipped"
+    else
+        echo -e "\nTest Cinder"
+        if cinder list; then
+            STATUS_CINDER="Succeeded"
+        else
+            STATUS_CINDER="Failed"
+            RETURN=1
+        fi
+    fi
+fi
+
+# Glance client
+# -------------
+
+if [[ "$ENABLED_SERVICES" =~ "g-api" ]]; then
+    if [[ "$SKIP_EXERCISES" =~ "g-api" ]]; then
+        STATUS_GLANCE="Skipped"
+    else
+        echo -e "\nTest Glance"
+        if openstack image list; then
+            STATUS_GLANCE="Succeeded"
+        else
+            STATUS_GLANCE="Failed"
+            RETURN=1
+        fi
+    fi
+fi
+
+# Swift client
+# ------------
+
+
+if [[ "$ENABLED_SERVICES" =~ "swift" || "$ENABLED_SERVICES" =~ "s-proxy" ]]; then
+    if [[ "$SKIP_EXERCISES" =~ "swift" ]]; then
+        STATUS_SWIFT="Skipped"
+    else
+        echo -e "\nTest Swift"
+        if swift stat; then
+            STATUS_SWIFT="Succeeded"
+        else
+            STATUS_SWIFT="Failed"
+            RETURN=1
+        fi
+    fi
+fi
+
+set +o xtrace
+
+
+# Results
+# =======
+
+function report {
+    if [[ -n "$2" ]]; then
+        echo "$1: $2"
+    fi
+}
+
+echo -e "\n"
+report "Keystone" $STATUS_KEYSTONE
+report "Nova" $STATUS_NOVA
+report "EC2" $STATUS_EC2
+report "Cinder" $STATUS_CINDER
+report "Glance" $STATUS_GLANCE
+report "Swift" $STATUS_SWIFT
+
+if (( $RETURN == 0 )); then
+    echo "*********************************************************************"
+    echo "SUCCESS: End DevStack Exercise: $0"
+    echo "*********************************************************************"
+fi
+
+exit $RETURN

exercises/euca.sh

@@ -0,0 +1,192 @@
+#!/usr/bin/env bash
+
+# **euca.sh**
+
+# we will use the ``euca2ools`` cli tool that wraps the python boto
+# library to test ec2 compatibility
+
+echo "*********************************************************************"
+echo "Begin DevStack Exercise: $0"
+echo "*********************************************************************"
+
+# This script exits on an error so that errors don't compound and you see
+# only the first error that occurred.
+set -o errexit
+
+# Print the commands being run so that we can see the command that triggers
+# an error.  It is also useful for following allowing as the install occurs.
+set -o xtrace
+
+
+# Settings
+# ========
+
+# Keep track of the current directory
+EXERCISE_DIR=$(cd $(dirname "$0") && pwd)
+TOP_DIR=$(cd $EXERCISE_DIR/..; pwd)
+VOLUME_SIZE=1
+ATTACH_DEVICE=/dev/vdc
+
+# Import common functions
+source $TOP_DIR/functions
+
+# Import EC2 configuration
+source $TOP_DIR/eucarc
+
+# Import exercise configuration
+source $TOP_DIR/exerciserc
+
+# Import project functions
+source $TOP_DIR/lib/neutron-legacy
+
+# If nova api is not enabled we exit with exitcode 55 so that
+# the exercise is skipped
+is_service_enabled n-api || exit 55
+
+# Instance type to create
+DEFAULT_INSTANCE_TYPE=${DEFAULT_INSTANCE_TYPE:-m1.tiny}
+
+# Boot this image, use first AMI image if unset
+DEFAULT_IMAGE_NAME=${DEFAULT_IMAGE_NAME:-ami}
+
+# Security group name
+SECGROUP=${SECGROUP:-euca_secgroup}
+
+
+# Launching a server
+# ==================
+
+# Find a machine image to boot
+IMAGE=`euca-describe-images | grep machine | grep ${DEFAULT_IMAGE_NAME} | cut -f2 | head -n1`
+die_if_not_set $LINENO IMAGE "Failure getting image $DEFAULT_IMAGE_NAME"
+
+if is_service_enabled n-cell; then
+    # Cells does not support security groups, so force the use of "default"
+    SECGROUP="default"
+    echo "Using the default security group because of Cells."
+else
+    # Add a secgroup
+    if ! euca-describe-groups | grep -q $SECGROUP; then
+        euca-add-group -d "$SECGROUP description" $SECGROUP
+        if ! timeout $ASSOCIATE_TIMEOUT sh -c "while ! euca-describe-groups | grep -q $SECGROUP; do sleep 1; done"; then
+            die $LINENO "Security group not created"
+        fi
+    fi
+fi
+
+# Launch it
+INSTANCE=`euca-run-instances -g $SECGROUP -t $DEFAULT_INSTANCE_TYPE $IMAGE | grep INSTANCE | cut -f2`
+die_if_not_set $LINENO INSTANCE "Failure launching instance"
+
+# Assure it has booted within a reasonable time
+if ! timeout $RUNNING_TIMEOUT sh -c "while ! euca-describe-instances $INSTANCE | grep -q running; do sleep 1; done"; then
+    die $LINENO "server didn't become active within $RUNNING_TIMEOUT seconds"
+fi
+
+# Volumes
+# -------
+if is_service_enabled c-vol && ! is_service_enabled n-cell && [ "$VIRT_DRIVER" != "ironic" ]; then
+    VOLUME_ZONE=`euca-describe-availability-zones | head -n1 | cut -f2`
+    die_if_not_set $LINENO VOLUME_ZONE "Failure to find zone for volume"
+
+    VOLUME=`euca-create-volume -s 1 -z $VOLUME_ZONE | cut -f2`
+    die_if_not_set $LINENO VOLUME "Failure to create volume"
+
+    # Test that volume has been created
+    VOLUME=`euca-describe-volumes $VOLUME | cut -f2`
+    die_if_not_set $LINENO VOLUME "Failure to get volume"
+
+    # Test volume has become available
+    if ! timeout $RUNNING_TIMEOUT sh -c "while ! euca-describe-volumes $VOLUME | grep -q available; do sleep 1; done"; then
+        die $LINENO "volume didn't become available within $RUNNING_TIMEOUT seconds"
+    fi
+
+    # Attach volume to an instance
+    euca-attach-volume -i $INSTANCE -d $ATTACH_DEVICE $VOLUME || \
+        die $LINENO "Failure attaching volume $VOLUME to $INSTANCE"
+    if ! timeout $ACTIVE_TIMEOUT sh -c "while ! euca-describe-volumes $VOLUME | grep -A 1 in-use | grep -q attach; do sleep 1; done"; then
+        die $LINENO "Could not attach $VOLUME to $INSTANCE"
+    fi
+
+    # Detach volume from an instance
+    euca-detach-volume $VOLUME || \
+        die $LINENO "Failure detaching volume $VOLUME to $INSTANCE"
+    if ! timeout $ACTIVE_TIMEOUT sh -c "while ! euca-describe-volumes $VOLUME | grep -q available; do sleep 1; done"; then
+        die $LINENO "Could not detach $VOLUME to $INSTANCE"
+    fi
+
+    # Remove volume
+    euca-delete-volume $VOLUME || \
+        die $LINENO "Failure to delete volume"
+    if ! timeout $ACTIVE_TIMEOUT sh -c "while euca-describe-volumes | grep $VOLUME; do sleep 1; done"; then
+        die $LINENO "Could not delete $VOLUME"
+    fi
+else
+    echo "Volume Tests Skipped"
+fi
+
+if is_service_enabled n-cell; then
+    echo "Floating IP Tests Skipped because of Cells."
+else
+    # Allocate floating address
+    FLOATING_IP=`euca-allocate-address | cut -f2`
+    die_if_not_set $LINENO FLOATING_IP "Failure allocating floating IP"
+    # describe all instances at this moment
+    euca-describe-instances
+    # Associate floating address
+    euca-associate-address -i $INSTANCE $FLOATING_IP || \
+        die $LINENO "Failure associating address $FLOATING_IP to $INSTANCE"
+
+    # Authorize pinging
+    euca-authorize -P icmp -s 0.0.0.0/0 -t -1:-1 $SECGROUP || \
+        die $LINENO "Failure authorizing rule in $SECGROUP"
+
+    # Test we can ping our floating ip within ASSOCIATE_TIMEOUT seconds
+    ping_check $FLOATING_IP $ASSOCIATE_TIMEOUT "$PUBLIC_NETWORK_NAME"
+
+    # Revoke pinging
+    euca-revoke -P icmp -s 0.0.0.0/0 -t -1:-1 $SECGROUP || \
+        die $LINENO "Failure revoking rule in $SECGROUP"
+
+    # Release floating address
+    euca-disassociate-address $FLOATING_IP || \
+        die $LINENO "Failure disassociating address $FLOATING_IP"
+
+    # Wait just a tick for everything above to complete so release doesn't fail
+    if ! timeout $ASSOCIATE_TIMEOUT sh -c "while euca-describe-addresses | grep $INSTANCE | grep -q $FLOATING_IP; do sleep 1; done"; then
+        die $LINENO "Floating ip $FLOATING_IP not disassociated within $ASSOCIATE_TIMEOUT seconds"
+    fi
+
+    # Release floating address
+    euca-release-address $FLOATING_IP || \
+        die $LINENO "Failure releasing address $FLOATING_IP"
+
+    # Wait just a tick for everything above to complete so terminate doesn't fail
+    if ! timeout $ASSOCIATE_TIMEOUT sh -c "while euca-describe-addresses | grep -q $FLOATING_IP; do sleep 1; done"; then
+        die $LINENO "Floating ip $FLOATING_IP not released within $ASSOCIATE_TIMEOUT seconds"
+    fi
+fi
+
+# Terminate instance
+euca-terminate-instances $INSTANCE || \
+    die $LINENO "Failure terminating instance $INSTANCE"
+
+# Assure it has terminated within a reasonable time. The behaviour of this
+# case changed with bug/836978. Requesting the status of an invalid instance
+# will now return an error message including the instance id, so we need to
+# filter that out.
+if ! timeout $TERMINATE_TIMEOUT sh -c "while euca-describe-instances $INSTANCE | grep -ve '\(InstanceNotFound\|InvalidInstanceID\.NotFound\)' | grep -q $INSTANCE; do sleep 1; done"; then
+    die $LINENO "server didn't terminate within $TERMINATE_TIMEOUT seconds"
+fi
+
+if [[ "$SECGROUP" = "default" ]] ; then
+    echo "Skipping deleting default security group"
+else
+    # Delete secgroup
+    euca-delete-group $SECGROUP || die $LINENO "Failure deleting security group $SECGROUP"
+fi
+
+set +o xtrace
+echo "*********************************************************************"
+echo "SUCCESS: End DevStack Exercise: $0"
+echo "*********************************************************************"

exercises/floating_ips.sh

@@ -0,0 +1,215 @@
+#!/usr/bin/env bash
+
+# **floating_ips.sh** - using the cloud can be fun
+
+# Test instance connectivity with the ``nova`` command from ``python-novaclient``
+
+echo "*********************************************************************"
+echo "Begin DevStack Exercise: $0"
+echo "*********************************************************************"
+
+# This script exits on an error so that errors don't compound and you see
+# only the first error that occurred.
+set -o errexit
+
+# Print the commands being run so that we can see the command that triggers
+# an error.  It is also useful for following allowing as the install occurs.
+set -o xtrace
+
+
+# Settings
+# ========
+
+# Keep track of the current directory
+EXERCISE_DIR=$(cd $(dirname "$0") && pwd)
+TOP_DIR=$(cd $EXERCISE_DIR/..; pwd)
+
+# Import common functions
+source $TOP_DIR/functions
+
+# Import configuration
+source $TOP_DIR/openrc
+
+# Import project functions
+source $TOP_DIR/lib/neutron-legacy
+
+# Import exercise configuration
+source $TOP_DIR/exerciserc
+
+# If nova api is not enabled we exit with exitcode 55 so that
+# the exercise is skipped
+is_service_enabled n-api || exit 55
+
+# Instance type to create
+DEFAULT_INSTANCE_TYPE=${DEFAULT_INSTANCE_TYPE:-m1.tiny}
+
+# Boot this image, use first AMI image if unset
+DEFAULT_IMAGE_NAME=${DEFAULT_IMAGE_NAME:-ami}
+
+# Security group name
+SECGROUP=${SECGROUP:-test_secgroup}
+
+# Default floating IP pool name
+DEFAULT_FLOATING_POOL=${DEFAULT_FLOATING_POOL:-public}
+
+# Additional floating IP pool and range
+TEST_FLOATING_POOL=${TEST_FLOATING_POOL:-test}
+
+# Instance name
+VM_NAME="ex-float"
+
+# Cells does not support floating ips API calls
+is_service_enabled n-cell && exit 55
+
+# Launching a server
+# ==================
+
+# List servers for tenant:
+nova list
+
+# Images
+# ------
+
+# List the images available
+openstack image list
+
+# Grab the id of the image to launch
+IMAGE=$(openstack image list | egrep " $DEFAULT_IMAGE_NAME " | get_field 1)
+die_if_not_set $LINENO IMAGE "Failure getting image $DEFAULT_IMAGE_NAME"
+
+# Security Groups
+# ---------------
+
+# List security groups
+nova secgroup-list
+
+# Create a secgroup
+if ! nova secgroup-list | grep -q $SECGROUP; then
+    nova secgroup-create $SECGROUP "$SECGROUP description"
+    if ! timeout $ASSOCIATE_TIMEOUT sh -c "while ! nova secgroup-list | grep -q $SECGROUP; do sleep 1; done"; then
+        die $LINENO "Security group not created"
+    fi
+fi
+
+# Configure Security Group Rules
+if ! nova secgroup-list-rules $SECGROUP | grep -q icmp; then
+    nova secgroup-add-rule $SECGROUP icmp -1 -1 0.0.0.0/0
+fi
+if ! nova secgroup-list-rules $SECGROUP | grep -q " tcp .* 22 "; then
+    nova secgroup-add-rule $SECGROUP tcp 22 22 0.0.0.0/0
+fi
+
+# List secgroup rules
+nova secgroup-list-rules $SECGROUP
+
+# Set up instance
+# ---------------
+
+# List flavors
+nova flavor-list
+
+# Select a flavor
+INSTANCE_TYPE=$(nova flavor-list | grep $DEFAULT_INSTANCE_TYPE | get_field 1)
+if [[ -z "$INSTANCE_TYPE" ]]; then
+    # grab the first flavor in the list to launch if default doesn't exist
+    INSTANCE_TYPE=$(nova flavor-list | head -n 4 | tail -n 1 | get_field 1)
+    die_if_not_set $LINENO INSTANCE_TYPE "Failure retrieving INSTANCE_TYPE"
+fi
+
+# Clean-up from previous runs
+nova delete $VM_NAME || true
+if ! timeout $ACTIVE_TIMEOUT sh -c "while nova show $VM_NAME; do sleep 1; done"; then
+    die $LINENO "server didn't terminate!"
+    exit 1
+fi
+
+# Boot instance
+# -------------
+
+VM_UUID=$(nova boot --flavor $INSTANCE_TYPE --image $IMAGE --security-groups=$SECGROUP $VM_NAME | grep ' id ' | get_field 2)
+die_if_not_set $LINENO VM_UUID "Failure launching $VM_NAME"
+
+# Check that the status is active within ACTIVE_TIMEOUT seconds
+if ! timeout $ACTIVE_TIMEOUT sh -c "while ! nova show $VM_UUID | grep status | grep -q ACTIVE; do sleep 1; done"; then
+    die $LINENO "server didn't become active!"
+fi
+
+# Get the instance IP
+IP=$(get_instance_ip $VM_UUID $PRIVATE_NETWORK_NAME)
+die_if_not_set $LINENO IP "Failure retrieving IP address"
+
+# Private IPs can be pinged in single node deployments
+ping_check $IP $BOOT_TIMEOUT "$PRIVATE_NETWORK_NAME"
+
+# Floating IPs
+# ------------
+
+# Allocate a floating IP from the default pool
+FLOATING_IP=$(nova floating-ip-create | grep $DEFAULT_FLOATING_POOL | get_field 1)
+die_if_not_set $LINENO FLOATING_IP "Failure creating floating IP from pool $DEFAULT_FLOATING_POOL"
+
+# List floating addresses
+if ! timeout $ASSOCIATE_TIMEOUT sh -c "while ! nova floating-ip-list | grep -q $FLOATING_IP; do sleep 1; done"; then
+    die $LINENO "Floating IP not allocated"
+fi
+
+# Add floating IP to our server
+nova add-floating-ip $VM_UUID $FLOATING_IP || \
+    die $LINENO "Failure adding floating IP $FLOATING_IP to $VM_NAME"
+
+# Test we can ping our floating IP within ASSOCIATE_TIMEOUT seconds
+ping_check $FLOATING_IP $ASSOCIATE_TIMEOUT "$PUBLIC_NETWORK_NAME"
+
+if ! is_service_enabled neutron; then
+    # Allocate an IP from second floating pool
+    TEST_FLOATING_IP=$(nova floating-ip-create $TEST_FLOATING_POOL | grep $TEST_FLOATING_POOL | get_field 1)
+    die_if_not_set $LINENO TEST_FLOATING_IP "Failure creating floating IP in $TEST_FLOATING_POOL"
+
+    # list floating addresses
+    if ! timeout $ASSOCIATE_TIMEOUT sh -c "while ! nova floating-ip-list | grep $TEST_FLOATING_POOL | grep -q $TEST_FLOATING_IP; do sleep 1; done"; then
+        die $LINENO "Floating IP not allocated"
+    fi
+fi
+
+# Dis-allow icmp traffic (ping)
+nova secgroup-delete-rule $SECGROUP icmp -1 -1 0.0.0.0/0 || \
+    die $LINENO "Failure deleting security group rule from $SECGROUP"
+
+if ! timeout $ASSOCIATE_TIMEOUT sh -c "while nova secgroup-list-rules $SECGROUP | grep -q icmp; do sleep 1; done"; then
+    die $LINENO "Security group rule not deleted from $SECGROUP"
+fi
+
+# FIXME (anthony): make xs support security groups
+if [ "$VIRT_DRIVER" != "ironic" -a "$VIRT_DRIVER" != "xenserver" -a "$VIRT_DRIVER" != "openvz" ]; then
+    # Test we can aren't able to ping our floating ip within ASSOCIATE_TIMEOUT seconds
+    ping_check $FLOATING_IP $ASSOCIATE_TIMEOUT "$PUBLIC_NETWORK_NAME" Fail
+fi
+
+# Clean up
+# --------
+
+if ! is_service_enabled neutron; then
+    # Delete second floating IP
+    nova floating-ip-delete $TEST_FLOATING_IP || \
+        die $LINENO "Failure deleting floating IP $TEST_FLOATING_IP"
+fi
+
+# Delete the floating ip
+nova floating-ip-delete $FLOATING_IP || \
+    die $LINENO "Failure deleting floating IP $FLOATING_IP"
+
+# Delete instance
+nova delete $VM_UUID || die $LINENO "Failure deleting instance $VM_NAME"
+# Wait for termination
+if ! timeout $TERMINATE_TIMEOUT sh -c "while nova list | grep -q $VM_UUID; do sleep 1; done"; then
+    die $LINENO "Server $VM_NAME not deleted"
+fi
+
+# Delete secgroup
+nova secgroup-delete $SECGROUP || \
+    die $LINENO "Failure deleting security group $SECGROUP"
+
+set +o xtrace
+echo "*********************************************************************"
+echo "SUCCESS: End DevStack Exercise: $0"
+echo "*********************************************************************"

exercises/neutron-adv-test.sh

@@ -0,0 +1,453 @@
+#!/usr/bin/env bash
+#
+# Copyright 2012, Cisco Systems
+# Copyright 2012, VMware, Inc.
+# Copyright 2012, NTT MCL, Inc.
+#
+# Please direct any questions to dedutta@cisco.com, dwendlandt@vmware.com, nachi@nttmcl.com
+#
+# **neutron-adv-test.sh**
+
+# Perform integration testing of Nova and other components with Neutron.
+
+echo "*********************************************************************"
+echo "Begin DevStack Exercise: $0"
+echo "*********************************************************************"
+
+# This script exits on an error so that errors don't compound and you see
+# only the first error that occurred.
+
+set -o errtrace
+
+# Print the commands being run so that we can see the command that triggers
+# an error.  It is also useful for following allowing as the install occurs.
+set -o xtrace
+
+# Environment
+# -----------
+
+# Keep track of the current directory
+EXERCISE_DIR=$(cd $(dirname "$0") && pwd)
+TOP_DIR=$(cd $EXERCISE_DIR/..; pwd)
+
+# Import common functions
+source $TOP_DIR/functions
+
+# Import configuration
+source $TOP_DIR/openrc
+
+# Import neutron functions
+source $TOP_DIR/lib/neutron-legacy
+
+# If neutron is not enabled we exit with exitcode 55, which means exercise is skipped.
+neutron_plugin_check_adv_test_requirements || exit 55
+
+# Import exercise configuration
+source $TOP_DIR/exerciserc
+
+# Neutron Settings
+# ----------------
+
+TENANTS="DEMO1"
+# TODO (nati)_Test public network
+#TENANTS="DEMO1,DEMO2"
+
+PUBLIC_NAME="admin"
+DEMO1_NAME="demo1"
+DEMO2_NAME="demo2"
+
+PUBLIC_NUM_NET=1
+DEMO1_NUM_NET=1
+DEMO2_NUM_NET=2
+
+PUBLIC_NET1_CIDR="200.0.0.0/24"
+DEMO1_NET1_CIDR="10.10.0.0/24"
+DEMO2_NET1_CIDR="10.20.0.0/24"
+DEMO2_NET2_CIDR="10.20.1.0/24"
+
+PUBLIC_NET1_GATEWAY="200.0.0.1"
+DEMO1_NET1_GATEWAY="10.10.0.1"
+DEMO2_NET1_GATEWAY="10.20.0.1"
+DEMO2_NET2_GATEWAY="10.20.1.1"
+
+PUBLIC_NUM_VM=1
+DEMO1_NUM_VM=1
+DEMO2_NUM_VM=2
+
+PUBLIC_VM1_NET='admin-net1'
+DEMO1_VM1_NET='demo1-net1'
+# Multinic settings. But this is fail without nic setting in OS image
+DEMO2_VM1_NET='demo2-net1'
+DEMO2_VM2_NET='demo2-net2'
+
+PUBLIC_NUM_ROUTER=1
+DEMO1_NUM_ROUTER=1
+DEMO2_NUM_ROUTER=1
+
+PUBLIC_ROUTER1_NET="admin-net1"
+DEMO1_ROUTER1_NET="demo1-net1"
+DEMO2_ROUTER1_NET="demo2-net1"
+
+# Various functions
+# -----------------
+
+function foreach_tenant {
+    COMMAND=$1
+    for TENANT in ${TENANTS//,/ };do
+        eval ${COMMAND//%TENANT%/$TENANT}
+    done
+}
+
+function foreach_tenant_resource {
+    COMMAND=$1
+    RESOURCE=$2
+    for TENANT in ${TENANTS//,/ };do
+        eval 'NUM=$'"${TENANT}_NUM_$RESOURCE"
+        for i in `seq $NUM`;do
+            local COMMAND_LOCAL=${COMMAND//%TENANT%/$TENANT}
+            COMMAND_LOCAL=${COMMAND_LOCAL//%NUM%/$i}
+            eval $COMMAND_LOCAL
+        done
+    done
+}
+
+function foreach_tenant_vm {
+    COMMAND=$1
+    foreach_tenant_resource "$COMMAND" 'VM'
+}
+
+function foreach_tenant_net {
+    COMMAND=$1
+    foreach_tenant_resource "$COMMAND" 'NET'
+}
+
+function get_image_id {
+    local IMAGE_ID=$(openstack image list | egrep " $DEFAULT_IMAGE_NAME " | get_field 1)
+    die_if_not_set $LINENO IMAGE_ID "Failure retrieving IMAGE_ID"
+    echo "$IMAGE_ID"
+}
+
+function get_tenant_id {
+    local TENANT_NAME=$1
+    local TENANT_ID=`openstack project list | grep " $TENANT_NAME " | head -n 1 | get_field 1`
+    die_if_not_set $LINENO TENANT_ID "Failure retrieving TENANT_ID for $TENANT_NAME"
+    echo "$TENANT_ID"
+}
+
+function get_user_id {
+    local USER_NAME=$1
+    local USER_ID=`openstack user list | grep $USER_NAME | awk '{print $2}'`
+    die_if_not_set $LINENO USER_ID "Failure retrieving USER_ID for $USER_NAME"
+    echo "$USER_ID"
+}
+
+function get_role_id {
+    local ROLE_NAME=$1
+    local ROLE_ID=`openstack role list | grep $ROLE_NAME | awk '{print $2}'`
+    die_if_not_set $LINENO ROLE_ID "Failure retrieving ROLE_ID for $ROLE_NAME"
+    echo "$ROLE_ID"
+}
+
+function get_network_id {
+    local NETWORK_NAME="$1"
+    local NETWORK_ID=`neutron net-list -F id  -- --name=$NETWORK_NAME | awk "NR==4" | awk '{print $2}'`
+    echo $NETWORK_ID
+}
+
+function get_flavor_id {
+    local INSTANCE_TYPE=$1
+    local FLAVOR_ID=`nova flavor-list | grep $INSTANCE_TYPE | awk '{print $2}'`
+    die_if_not_set $LINENO FLAVOR_ID "Failure retrieving FLAVOR_ID for $INSTANCE_TYPE"
+    echo "$FLAVOR_ID"
+}
+
+function confirm_server_active {
+    local VM_UUID=$1
+    if ! timeout $ACTIVE_TIMEOUT sh -c "while ! nova show $VM_UUID | grep status | grep -q ACTIVE; do sleep 1; done"; then
+        echo "server '$VM_UUID' did not become active!"
+        false
+    fi
+}
+
+function neutron_debug_admin {
+    local os_username=$OS_USERNAME
+    local os_tenant_id=$OS_TENANT_ID
+    source $TOP_DIR/openrc admin admin
+    neutron-debug $@
+    source $TOP_DIR/openrc $os_username $os_tenant_id
+}
+
+function add_tenant {
+    openstack project create $1
+    openstack user create $2 --password ${ADMIN_PASSWORD} --project $1
+    openstack role add Member --project $1 --user $2
+}
+
+function remove_tenant {
+    local TENANT=$1
+    local TENANT_ID=$(get_tenant_id $TENANT)
+    openstack project delete $TENANT_ID
+}
+
+function remove_user {
+    local USER=$1
+    local USER_ID=$(get_user_id $USER)
+    openstack user delete $USER_ID
+}
+
+function create_tenants {
+    source $TOP_DIR/openrc admin admin
+    add_tenant demo1 demo1 demo1
+    add_tenant demo2 demo2 demo2
+    source $TOP_DIR/openrc demo demo
+}
+
+function delete_tenants_and_users {
+    source $TOP_DIR/openrc admin admin
+    remove_user demo1
+    remove_tenant demo1
+    remove_user demo2
+    remove_tenant demo2
+    echo "removed all tenants"
+    source $TOP_DIR/openrc demo demo
+}
+
+function create_network {
+    local TENANT=$1
+    local GATEWAY=$2
+    local CIDR=$3
+    local NUM=$4
+    local EXTRA=$5
+    local NET_NAME="${TENANT}-net$NUM"
+    local ROUTER_NAME="${TENANT}-router${NUM}"
+    source $TOP_DIR/openrc admin admin
+    local TENANT_ID=$(get_tenant_id $TENANT)
+    source $TOP_DIR/openrc $TENANT $TENANT
+    local NET_ID=$(neutron net-create --tenant-id $TENANT_ID $NET_NAME $EXTRA| grep ' id ' | awk '{print $4}' )
+    die_if_not_set $LINENO NET_ID "Failure creating NET_ID for $TENANT_ID $NET_NAME $EXTRA"
+    neutron subnet-create --ip-version 4 --tenant-id $TENANT_ID --gateway $GATEWAY $NET_ID $CIDR
+    neutron_debug_admin probe-create --device-owner compute $NET_ID
+    source $TOP_DIR/openrc demo demo
+}
+
+function create_networks {
+    foreach_tenant_net 'create_network ${%TENANT%_NAME} ${%TENANT%_NET%NUM%_GATEWAY} ${%TENANT%_NET%NUM%_CIDR} %NUM% ${%TENANT%_NET%NUM%_EXTRA}'
+    #TODO(nati) test security group function
+    # allow ICMP for both tenant's security groups
+    #source $TOP_DIR/openrc demo1 demo1
+    #$NOVA secgroup-add-rule default icmp -1 -1 0.0.0.0/0
+    #source $TOP_DIR/openrc demo2 demo2
+    #$NOVA secgroup-add-rule default icmp -1 -1 0.0.0.0/0
+}
+
+function create_vm {
+    local TENANT=$1
+    local NUM=$2
+    local NET_NAMES=$3
+    source $TOP_DIR/openrc $TENANT $TENANT
+    local NIC=""
+    for NET_NAME in ${NET_NAMES//,/ };do
+        NIC="$NIC --nic net-id="`get_network_id $NET_NAME`
+    done
+    #TODO (nati) Add multi-nic test
+    #TODO (nati) Add public-net test
+    local VM_UUID=`nova boot --flavor $(get_flavor_id m1.tiny) \
+        --image $(get_image_id) \
+        $NIC \
+        $TENANT-server$NUM | grep ' id ' | cut -d"|" -f3 | sed 's/ //g'`
+    die_if_not_set $LINENO VM_UUID "Failure launching $TENANT-server$NUM"
+    confirm_server_active $VM_UUID
+}
+
+function create_vms {
+    foreach_tenant_vm 'create_vm ${%TENANT%_NAME} %NUM% ${%TENANT%_VM%NUM%_NET}'
+}
+
+function ping_ip {
+    # Test agent connection.  Assumes namespaces are disabled, and
+    # that DHCP is in use, but not L3
+    local VM_NAME=$1
+    local NET_NAME=$2
+    IP=$(get_instance_ip $VM_NAME $NET_NAME)
+    ping_check $IP $BOOT_TIMEOUT $NET_NAME
+}
+
+function check_vm {
+    local TENANT=$1
+    local NUM=$2
+    local VM_NAME="$TENANT-server$NUM"
+    local NET_NAME=$3
+    source $TOP_DIR/openrc $TENANT $TENANT
+    ping_ip $VM_NAME $NET_NAME
+    # TODO (nati) test ssh connection
+    # TODO (nati) test inter connection between vm
+    # TODO (nati) test dhcp host routes
+    # TODO (nati) test multi-nic
+}
+
+function check_vms {
+    foreach_tenant_vm 'check_vm ${%TENANT%_NAME} %NUM% ${%TENANT%_VM%NUM%_NET}'
+}
+
+function shutdown_vm {
+    local TENANT=$1
+    local NUM=$2
+    source $TOP_DIR/openrc $TENANT $TENANT
+    VM_NAME=${TENANT}-server$NUM
+    nova delete $VM_NAME
+}
+
+function shutdown_vms {
+    foreach_tenant_vm 'shutdown_vm ${%TENANT%_NAME} %NUM%'
+    if ! timeout $TERMINATE_TIMEOUT sh -c "while nova list | grep -q ACTIVE; do sleep 1; done"; then
+        die $LINENO "Some VMs failed to shutdown"
+    fi
+}
+
+function delete_network {
+    local TENANT=$1
+    local NUM=$2
+    local NET_NAME="${TENANT}-net$NUM"
+    source $TOP_DIR/openrc admin admin
+    local TENANT_ID=$(get_tenant_id $TENANT)
+    #TODO(nati) comment out until l3-agent merged
+    #for res in port subnet net router;do
+    for net_id in `neutron net-list -c id -c name | grep $NET_NAME | awk '{print $2}'`;do
+        delete_probe $net_id
+        neutron subnet-list | grep $net_id | awk '{print $2}' | xargs -I% neutron subnet-delete %
+        neutron net-delete $net_id
+    done
+    source $TOP_DIR/openrc demo demo
+}
+
+function delete_networks {
+    foreach_tenant_net 'delete_network ${%TENANT%_NAME} %NUM%'
+    # TODO(nati) add secuirty group check after it is implemented
+    # source $TOP_DIR/openrc demo1 demo1
+    # nova secgroup-delete-rule default icmp -1 -1 0.0.0.0/0
+    # source $TOP_DIR/openrc demo2 demo2
+    # nova secgroup-delete-rule default icmp -1 -1 0.0.0.0/0
+}
+
+function create_all {
+    create_tenants
+    create_networks
+    create_vms
+}
+
+function delete_all {
+    shutdown_vms
+    delete_networks
+    delete_tenants_and_users
+}
+
+function all {
+    create_all
+    check_vms
+    delete_all
+}
+
+# Test functions
+# --------------
+
+function test_functions {
+    IMAGE=$(get_image_id)
+    echo $IMAGE
+
+    TENANT_ID=$(get_tenant_id demo)
+    echo $TENANT_ID
+
+    FLAVOR_ID=$(get_flavor_id m1.tiny)
+    echo $FLAVOR_ID
+
+    NETWORK_ID=$(get_network_id admin)
+    echo $NETWORK_ID
+}
+
+# Usage and main
+# --------------
+
+function usage {
+    echo "$0: [-h]"
+    echo "  -h, --help              Display help message"
+    echo "  -t, --tenant            Create tenants"
+    echo "  -n, --net               Create networks"
+    echo "  -v, --vm                Create vms"
+    echo "  -c, --check             Check connection"
+    echo "  -x, --delete-tenants    Delete tenants"
+    echo "  -y, --delete-nets       Delete networks"
+    echo "  -z, --delete-vms        Delete vms"
+    echo "  -T, --test              Test functions"
+}
+
+function main {
+
+    echo Description
+
+    if [ $# -eq 0 ] ; then
+        # if no args are provided, run all tests
+        all
+    else
+
+        while [ "$1" != "" ]; do
+            case $1 in
+                -h | --help )   usage
+                                exit
+                                ;;
+                -n | --net )    create_networks
+                                exit
+                                ;;
+                -v | --vm )     create_vms
+                                exit
+                                ;;
+                -t | --tenant ) create_tenants
+                                exit
+                                ;;
+                -c | --check )   check_vms
+                                exit
+                                ;;
+                -T | --test )   test_functions
+                                exit
+                                ;;
+                -x | --delete-tenants ) delete_tenants_and_users
+                                exit
+                                ;;
+                -y | --delete-nets ) delete_networks
+                                exit
+                                ;;
+                -z | --delete-vms ) shutdown_vms
+                                exit
+                                ;;
+                -a | --all )    all
+                                exit
+                                ;;
+                * )             usage
+                                exit 1
+            esac
+            shift
+        done
+    fi
+}
+
+trap failed ERR
+function failed {
+    local r=$?
+    set +o errtrace
+    set +o xtrace
+    echo "Failed to execute"
+    echo "Starting cleanup..."
+    delete_all
+    echo "Finished cleanup"
+    exit $r
+}
+
+# Kick off script
+# ---------------
+
+echo $*
+main $*
+
+set +o xtrace
+echo "*********************************************************************"
+echo "SUCCESS: End DevStack Exercise: $0"
+echo "*********************************************************************"

exercises/sec_groups.sh

@@ -0,0 +1,81 @@
+#!/usr/bin/env bash
+
+# **sec_groups.sh**
+
+# Test security groups via the command line
+
+echo "*********************************************************************"
+echo "Begin DevStack Exercise: $0"
+echo "*********************************************************************"
+
+# This script exits on an error so that errors don't compound and you see
+# only the first error that occurred.
+set -o errexit
+
+# Print the commands being run so that we can see the command that triggers
+# an error.  It is also useful for following allowing as the install occurs.
+set -o xtrace
+
+
+# Settings
+# ========
+
+# Keep track of the current directory
+EXERCISE_DIR=$(cd $(dirname "$0") && pwd)
+TOP_DIR=$(cd $EXERCISE_DIR/..; pwd)
+
+# Import common functions
+source $TOP_DIR/functions
+
+# Import configuration
+source $TOP_DIR/openrc
+
+# Import exercise configuration
+source $TOP_DIR/exerciserc
+
+# If nova api is not enabled we exit with exitcode 55 so that
+# the exercise is skipped
+is_service_enabled n-api || exit 55
+
+
+# Testing Security Groups
+# =======================
+
+# List security groups
+nova secgroup-list
+
+# Create random name for new sec group and create secgroup of said name
+SEC_GROUP_NAME="ex-secgroup-$(openssl rand -hex 4)"
+nova secgroup-create $SEC_GROUP_NAME 'a test security group'
+
+# Add some rules to the secgroup
+RULES_TO_ADD=( 22 3389 5900 )
+
+for RULE in "${RULES_TO_ADD[@]}"; do
+    nova secgroup-add-rule $SEC_GROUP_NAME tcp $RULE $RULE 0.0.0.0/0
+done
+
+# Check to make sure rules were added
+SEC_GROUP_RULES=( $(nova secgroup-list-rules $SEC_GROUP_NAME | grep -v \- | grep -v 'Source Group' | cut -d '|' -f3 | tr -d ' ') )
+die_if_not_set $LINENO SEC_GROUP_RULES "Failure retrieving SEC_GROUP_RULES for $SEC_GROUP_NAME"
+for i in "${RULES_TO_ADD[@]}"; do
+    skip=
+    for j in "${SEC_GROUP_RULES[@]}"; do
+        [[ $i == $j ]] && { skip=1; break; }
+    done
+    [[ -n $skip ]] || exit 1
+done
+
+# Delete rules and secgroup
+for RULE in "${RULES_TO_ADD[@]}"; do
+    nova secgroup-delete-rule $SEC_GROUP_NAME tcp $RULE $RULE 0.0.0.0/0
+done
+
+# Delete secgroup
+nova secgroup-delete $SEC_GROUP_NAME || \
+    die $LINENO "Failure deleting security group $SEC_GROUP_NAME"
+
+set +o xtrace
+echo "*********************************************************************"
+echo "SUCCESS: End DevStack Exercise: $0"
+echo "*********************************************************************"

exercises/swift.sh

@@ -0,0 +1,66 @@
+#!/usr/bin/env bash
+
+# **swift.sh**
+
+# Test swift via the ``swift`` command line from ``python-swiftclient``
+
+echo "*********************************************************************"
+echo "Begin DevStack Exercise: $0"
+echo "*********************************************************************"
+
+# This script exits on an error so that errors don't compound and you see
+# only the first error that occurred.
+set -o errexit
+
+# Print the commands being run so that we can see the command that triggers
+# an error.  It is also useful for following allowing as the install occurs.
+set -o xtrace
+
+
+# Settings
+# ========
+
+# Keep track of the current directory
+EXERCISE_DIR=$(cd $(dirname "$0") && pwd)
+TOP_DIR=$(cd $EXERCISE_DIR/..; pwd)
+
+# Import common functions
+source $TOP_DIR/functions
+
+# Import configuration
+source $TOP_DIR/openrc
+
+# Import exercise configuration
+source $TOP_DIR/exerciserc
+
+# If swift is not enabled we exit with exitcode 55 which mean
+# exercise is skipped.
+is_service_enabled s-proxy || exit 55
+
+# Container name
+CONTAINER=ex-swift
+
+
+# Testing Swift
+# =============
+
+# Check if we have to swift via keystone
+swift stat || die $LINENO "Failure getting status"
+
+# We start by creating a test container
+openstack container create $CONTAINER || die $LINENO "Failure creating container $CONTAINER"
+
+# add some files into it.
+openstack object create $CONTAINER /etc/issue || die $LINENO "Failure uploading file to container $CONTAINER"
+
+# list them
+openstack object list $CONTAINER || die $LINENO "Failure listing contents of container $CONTAINER"
+
+# And we may want to delete them now that we have tested that
+# everything works.
+swift delete $CONTAINER || die $LINENO "Failure deleting container $CONTAINER"
+
+set +o xtrace
+echo "*********************************************************************"
+echo "SUCCESS: End DevStack Exercise: $0"
+echo "*********************************************************************"

exercises/volumes.sh

@@ -0,0 +1,224 @@
+#!/usr/bin/env bash
+
+# **volumes.sh**
+
+# Test cinder volumes with the ``cinder`` command from ``python-cinderclient``
+
+echo "*********************************************************************"
+echo "Begin DevStack Exercise: $0"
+echo "*********************************************************************"
+
+# This script exits on an error so that errors don't compound and you see
+# only the first error that occurred.
+set -o errexit
+
+# Print the commands being run so that we can see the command that triggers
+# an error.  It is also useful for following allowing as the install occurs.
+set -o xtrace
+
+
+# Settings
+# ========
+
+# Keep track of the current directory
+EXERCISE_DIR=$(cd $(dirname "$0") && pwd)
+TOP_DIR=$(cd $EXERCISE_DIR/..; pwd)
+
+# Import common functions
+source $TOP_DIR/functions
+
+# Import configuration
+source $TOP_DIR/openrc
+
+# Import project functions
+source $TOP_DIR/lib/cinder
+source $TOP_DIR/lib/neutron-legacy
+
+# Import exercise configuration
+source $TOP_DIR/exerciserc
+
+# If cinder is not enabled we exit with exitcode 55 which mean
+# exercise is skipped.
+is_service_enabled cinder || exit 55
+
+# Ironic does not currently support volume attachment.
+[ "$VIRT_DRIVER" == "ironic" ] && exit 55
+
+# Instance type to create
+DEFAULT_INSTANCE_TYPE=${DEFAULT_INSTANCE_TYPE:-m1.tiny}
+
+# Boot this image, use first AMI image if unset
+DEFAULT_IMAGE_NAME=${DEFAULT_IMAGE_NAME:-ami}
+
+# Security group name
+SECGROUP=${SECGROUP:-vol_secgroup}
+
+# Instance and volume names
+VM_NAME=${VM_NAME:-ex-vol-inst}
+VOL_NAME="ex-vol-$(openssl rand -hex 4)"
+
+
+# Launching a server
+# ==================
+
+# List servers for tenant:
+nova list
+
+# Images
+# ------
+
+# List the images available
+openstack image list
+
+# Grab the id of the image to launch
+IMAGE=$(openstack image list | egrep " $DEFAULT_IMAGE_NAME " | get_field 1)
+die_if_not_set $LINENO IMAGE "Failure getting image $DEFAULT_IMAGE_NAME"
+
+# Security Groups
+# ---------------
+
+# List security groups
+nova secgroup-list
+
+if is_service_enabled n-cell; then
+    # Cells does not support security groups, so force the use of "default"
+    SECGROUP="default"
+    echo "Using the default security group because of Cells."
+else
+    # Create a secgroup
+    if ! nova secgroup-list | grep -q $SECGROUP; then
+        nova secgroup-create $SECGROUP "$SECGROUP description"
+        if ! timeout $ASSOCIATE_TIMEOUT sh -c "while ! nova secgroup-list | grep -q $SECGROUP; do sleep 1; done"; then
+            echo "Security group not created"
+            exit 1
+        fi
+    fi
+fi
+
+# Configure Security Group Rules
+if ! nova secgroup-list-rules $SECGROUP | grep -q icmp; then
+    nova secgroup-add-rule $SECGROUP icmp -1 -1 0.0.0.0/0
+fi
+if ! nova secgroup-list-rules $SECGROUP | grep -q " tcp .* 22 "; then
+    nova secgroup-add-rule $SECGROUP tcp 22 22 0.0.0.0/0
+fi
+
+# List secgroup rules
+nova secgroup-list-rules $SECGROUP
+
+# Set up instance
+# ---------------
+
+# List flavors
+nova flavor-list
+
+# Select a flavor
+INSTANCE_TYPE=$(nova flavor-list | grep $DEFAULT_INSTANCE_TYPE | get_field 1)
+if [[ -z "$INSTANCE_TYPE" ]]; then
+    # grab the first flavor in the list to launch if default doesn't exist
+    INSTANCE_TYPE=$(nova flavor-list | head -n 4 | tail -n 1 | get_field 1)
+    die_if_not_set $LINENO INSTANCE_TYPE "Failure retrieving INSTANCE_TYPE"
+fi
+
+# Clean-up from previous runs
+nova delete $VM_NAME || true
+if ! timeout $ACTIVE_TIMEOUT sh -c "while nova show $VM_NAME; do sleep 1; done"; then
+    die $LINENO "server didn't terminate!"
+fi
+
+# Boot instance
+# -------------
+
+VM_UUID=$(nova boot --flavor $INSTANCE_TYPE --image $IMAGE --security-groups=$SECGROUP $VM_NAME | grep ' id ' | get_field 2)
+die_if_not_set $LINENO VM_UUID "Failure launching $VM_NAME"
+
+# Check that the status is active within ACTIVE_TIMEOUT seconds
+if ! timeout $ACTIVE_TIMEOUT sh -c "while ! nova show $VM_UUID | grep status | grep -q ACTIVE; do sleep 1; done"; then
+    die $LINENO "server didn't become active!"
+fi
+
+# Get the instance IP
+IP=$(get_instance_ip $VM_UUID $PRIVATE_NETWORK_NAME)
+
+die_if_not_set $LINENO IP "Failure retrieving IP address"
+
+# Private IPs can be pinged in single node deployments
+ping_check $IP $BOOT_TIMEOUT "$PRIVATE_NETWORK_NAME"
+
+# Volumes
+# -------
+
+# Verify it doesn't exist
+if [[ -n $(cinder list | grep $VOL_NAME | head -1 | get_field 2) ]]; then
+    die $LINENO "Volume $VOL_NAME already exists"
+fi
+
+# Create a new volume
+start_time=$(date +%s)
+cinder create --display-name $VOL_NAME --display-description "test volume: $VOL_NAME" $DEFAULT_VOLUME_SIZE || \
+    die $LINENO "Failure creating volume $VOL_NAME"
+if ! timeout $ACTIVE_TIMEOUT sh -c "while ! cinder list | grep $VOL_NAME | grep available; do sleep 1; done"; then
+    die $LINENO "Volume $VOL_NAME not created"
+fi
+end_time=$(date +%s)
+echo "Completed cinder create in $((end_time - start_time)) seconds"
+
+# Get volume ID
+VOL_ID=$(cinder list | grep $VOL_NAME | head -1 | get_field 1)
+die_if_not_set $LINENO VOL_ID "Failure retrieving volume ID for $VOL_NAME"
+
+# Attach to server
+DEVICE=/dev/vdb
+start_time=$(date +%s)
+nova volume-attach $VM_UUID $VOL_ID $DEVICE || \
+    die $LINENO "Failure attaching volume $VOL_NAME to $VM_NAME"
+if ! timeout $ACTIVE_TIMEOUT sh -c "while ! cinder list | grep $VOL_NAME | grep in-use; do sleep 1; done"; then
+    die $LINENO "Volume $VOL_NAME not attached to $VM_NAME"
+fi
+end_time=$(date +%s)
+echo "Completed volume-attach in $((end_time - start_time)) seconds"
+
+VOL_ATTACH=$(cinder list | grep $VOL_NAME | head -1 | get_field -1)
+die_if_not_set $LINENO VOL_ATTACH "Failure retrieving $VOL_NAME status"
+if [[ "$VOL_ATTACH" != $VM_UUID ]]; then
+    die $LINENO "Volume not attached to correct instance"
+fi
+
+# Clean up
+# --------
+
+# Detach volume
+start_time=$(date +%s)
+nova volume-detach $VM_UUID $VOL_ID || die $LINENO "Failure detaching volume $VOL_NAME from $VM_NAME"
+if ! timeout $ACTIVE_TIMEOUT sh -c "while ! cinder list | grep $VOL_NAME | grep available; do sleep 1; done"; then
+    die $LINENO "Volume $VOL_NAME not detached from $VM_NAME"
+fi
+end_time=$(date +%s)
+echo "Completed volume-detach in $((end_time - start_time)) seconds"
+
+# Delete volume
+start_time=$(date +%s)
+cinder delete $VOL_ID || die $LINENO "Failure deleting volume $VOL_NAME"
+if ! timeout $ACTIVE_TIMEOUT sh -c "while cinder list | grep $VOL_NAME; do sleep 1; done"; then
+    die $LINENO "Volume $VOL_NAME not deleted"
+fi
+end_time=$(date +%s)
+echo "Completed cinder delete in $((end_time - start_time)) seconds"
+
+# Delete instance
+nova delete $VM_UUID || die $LINENO "Failure deleting instance $VM_NAME"
+if ! timeout $TERMINATE_TIMEOUT sh -c "while nova list | grep -q $VM_UUID; do sleep 1; done"; then
+    die $LINENO "Server $VM_NAME not deleted"
+fi
+
+if [[ $SECGROUP = "default" ]] ; then
+    echo "Skipping deleting default security group"
+else
+    # Delete secgroup
+    nova secgroup-delete $SECGROUP || die $LINENO "Failure deleting security group $SECGROUP"
+fi
+
+set +o xtrace
+echo "*********************************************************************"
+echo "SUCCESS: End DevStack Exercise: $0"
+echo "*********************************************************************"

extras.d/50-ironic.sh

@@ -0,0 +1,43 @@
+# ironic.sh - Devstack extras script to install ironic
+
+if is_service_enabled ir-api ir-cond; then
+    if [[ "$1" == "source" ]]; then
+        # Initial source
+        source $TOP_DIR/lib/ironic
+    elif [[ "$1" == "stack" && "$2" == "install" ]]; then
+        echo_summary "Installing Ironic"
+        install_ironic
+        install_ironicclient
+        cleanup_ironic
+    elif [[ "$1" == "stack" && "$2" == "post-config" ]]; then
+        echo_summary "Configuring Ironic"
+        configure_ironic
+
+        if is_service_enabled key; then
+            create_ironic_accounts
+        fi
+
+    elif [[ "$1" == "stack" && "$2" == "extra" ]]; then
+        # Initialize ironic
+        init_ironic
+
+        # Start the ironic API and ironic taskmgr components
+        echo_summary "Starting Ironic"
+        start_ironic
+
+        if [[ "$IRONIC_BAREMETAL_BASIC_OPS" = "True" ]]; then
+            prepare_baremetal_basic_ops
+        fi
+    fi
+
+    if [[ "$1" == "unstack" ]]; then
+        stop_ironic
+        if [[ "$IRONIC_BAREMETAL_BASIC_OPS" = "True" ]]; then
+            cleanup_baremetal_basic_ops
+        fi
+    fi
+
+    if [[ "$1" == "clean" ]]; then
+        cleanup_ironic
+    fi
+fi

extras.d/60-ceph.sh

@@ -0,0 +1,75 @@
+# ceph.sh - DevStack extras script to install Ceph
+
+if is_service_enabled ceph; then
+    if [[ "$1" == "source" ]]; then
+        # Initial source
+        source $TOP_DIR/lib/ceph
+    elif [[ "$1" == "stack" && "$2" == "pre-install" ]]; then
+        echo_summary "Installing Ceph"
+        check_os_support_ceph
+        if [ "$REMOTE_CEPH" = "False" ]; then
+            install_ceph
+            echo_summary "Configuring Ceph"
+            configure_ceph
+            # NOTE (leseb): Do everything here because we need to have Ceph started before the main
+            # OpenStack components. Ceph OSD must start here otherwise we can't upload any images.
+            echo_summary "Initializing Ceph"
+            init_ceph
+            start_ceph
+        else
+            install_ceph_remote
+        fi
+    elif [[ "$1" == "stack" && "$2" == "post-config" ]]; then
+        if is_service_enabled glance; then
+            echo_summary "Configuring Glance for Ceph"
+            configure_ceph_glance
+        fi
+        if is_service_enabled nova; then
+            echo_summary "Configuring Nova for Ceph"
+            configure_ceph_nova
+        fi
+        if is_service_enabled cinder; then
+            echo_summary "Configuring Cinder for Ceph"
+            configure_ceph_cinder
+        fi
+        if is_service_enabled cinder || is_service_enabled nova; then
+            # NOTE (leseb): the part below is a requirement to attach Ceph block devices
+            echo_summary "Configuring libvirt secret"
+            import_libvirt_secret_ceph
+        fi
+
+        if [ "$REMOTE_CEPH" = "False" ]; then
+            if is_service_enabled glance; then
+                echo_summary "Configuring Glance for Ceph"
+                configure_ceph_embedded_glance
+            fi
+            if is_service_enabled nova; then
+                echo_summary "Configuring Nova for Ceph"
+                configure_ceph_embedded_nova
+            fi
+            if is_service_enabled cinder; then
+                echo_summary "Configuring Cinder for Ceph"
+                configure_ceph_embedded_cinder
+            fi
+        fi
+    fi
+
+    if [[ "$1" == "unstack" ]]; then
+        if [ "$REMOTE_CEPH" = "True" ]; then
+            cleanup_ceph_remote
+        else
+            cleanup_ceph_embedded
+            stop_ceph
+        fi
+        cleanup_ceph_general
+    fi
+
+    if [[ "$1" == "clean" ]]; then
+        if [ "$REMOTE_CEPH" = "True" ]; then
+            cleanup_ceph_remote
+        else
+            cleanup_ceph_embedded
+        fi
+        cleanup_ceph_general
+    fi
+fi

extras.d/80-tempest.sh

@@ -6,22 +6,19 @@ if is_service_enabled tempest; then
         source $TOP_DIR/lib/tempest
     elif [[ "$1" == "stack" && "$2" == "install" ]]; then
         echo_summary "Installing Tempest"
-        async_runfunc install_tempest
+        install_tempest
     elif [[ "$1" == "stack" && "$2" == "post-config" ]]; then
         # Tempest config must come after layer 2 services are running
-        :
+        create_tempest_accounts
     elif [[ "$1" == "stack" && "$2" == "extra" ]]; then
-        # Tempest config must come after all other plugins are run
-        :
+        echo_summary "Initializing Tempest"
+        configure_tempest
+        init_tempest
+        echo_summary "Installing Tempest Plugins"
+        install_tempest_plugins
     elif [[ "$1" == "stack" && "$2" == "post-extra" ]]; then
         # local.conf Tempest option overrides
         :
-    elif [[ "$1" == "stack" && "$2" == "test-config" ]]; then
-        async_wait install_tempest
-        echo_summary "Initializing Tempest"
-        configure_tempest
-        echo_summary "Installing Tempest Plugins"
-        install_tempest_plugins
     fi
 
     if [[ "$1" == "unstack" ]]; then
@@ -34,3 +31,4 @@ if is_service_enabled tempest; then
         :
     fi
 fi
+

extras.d/README.md

@@ -14,13 +14,10 @@ The scripts are sourced at the beginning of each script that calls them. The
 entire `stack.sh` variable space is available.  The scripts are
 sourced with one or more arguments, the first of which defines the hook phase:
 
-    override_defaults | source | stack | unstack | clean
+    source | stack | unstack | clean
 
-    override_defaults: always called first in any of the scripts, used to
-        override defaults (if need be) that are otherwise set in lib/* scripts
-
-    source: called by stack.sh. Used to set the initial defaults in a lib/*
-        script or similar
+    source: always called first in any of the scripts, used to set the
+        initial defaults in a lib/* script or similar
 
     stack: called by stack.sh.  There are four possible values for
         the second arg to distinguish the phase stack.sh is in:

files/apache-cinder-api.template

@@ -1,26 +0,0 @@
-Listen %PUBLICPORT%
-
-<VirtualHost *:%PUBLICPORT%>
-    WSGIDaemonProcess osapi_volume processes=%APIWORKERS% threads=1 user=%USER% display-name=%{GROUP} %VIRTUALENV%
-    WSGIProcessGroup osapi_volume
-    WSGIScriptAlias / %CINDER_BIN_DIR%/cinder-wsgi
-    WSGIApplicationGroup %{GLOBAL}
-    WSGIPassAuthorization On
-    <IfVersion >= 2.4>
-      ErrorLogFormat "%{cu}t %M"
-    </IfVersion>
-    ErrorLog /var/log/%APACHE_NAME%/c-api.log
-    %SSLENGINE%
-    %SSLCERTFILE%
-    %SSLKEYFILE%
-
-    <Directory %CINDER_BIN_DIR%>
-        <IfVersion >= 2.4>
-            Require all granted
-        </IfVersion>
-        <IfVersion < 2.4>
-            Order allow,deny
-            Allow from all
-        </IfVersion>
-    </Directory>
-</VirtualHost>

files/apache-heat-pip-repo.template

@@ -0,0 +1,15 @@
+Listen %HEAT_PIP_REPO_PORT%
+
+<VirtualHost *:%HEAT_PIP_REPO_PORT%>
+    DocumentRoot %HEAT_PIP_REPO%
+    <Directory %HEAT_PIP_REPO%>
+        DirectoryIndex index.html
+        Require all granted
+        Order allow,deny
+        allow from all
+    </Directory>
+
+    ErrorLog /var/log/%APACHE_NAME%/heat_pip_repo_error.log
+    LogLevel warn
+    CustomLog /var/log/%APACHE_NAME%/heat_pip_repo_access.log combined
+</VirtualHost>

files/apache-horizon.template

@@ -1,5 +1,5 @@
 <VirtualHost *:80>
-    WSGIScriptAlias %WEBROOT% %HORIZON_DIR%/openstack_dashboard/wsgi.py
+    WSGIScriptAlias %WEBROOT% %HORIZON_DIR%/openstack_dashboard/wsgi/django.wsgi
     WSGIDaemonProcess horizon user=%USER% group=%GROUP% processes=3 threads=10 home=%HORIZON_DIR% display-name=%{GROUP}
     WSGIApplicationGroup %{GLOBAL}
 
@@ -39,5 +39,4 @@
     CustomLog /var/log/%APACHE_NAME%/horizon_access.log combined
 </VirtualHost>
 
-%WSGIPYTHONHOME%
 WSGISocketPrefix /var/run/%APACHE_NAME%

files/apache-ironic.template

@@ -0,0 +1,12 @@
+Listen %PUBLICPORT%
+
+<VirtualHost *:%PUBLICPORT%>
+    DocumentRoot "%HTTPROOT%"
+    <Directory "%HTTPROOT%">
+        Options Indexes FollowSymLinks
+        AllowOverride None
+        Order allow,deny
+        Allow from all
+        Require all granted
+    </Directory>
+</VirtualHost>

files/apache-keystone.template

@@ -1,32 +1,60 @@
 Listen %PUBLICPORT%
+Listen %ADMINPORT%
 LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\" %D(us)" keystone_combined
 
-<Directory %KEYSTONE_BIN%>
-    Require all granted
-</Directory>
-
 <VirtualHost *:%PUBLICPORT%>
-    WSGIDaemonProcess keystone-public processes=3 threads=1 user=%USER% display-name=%{GROUP} %VIRTUALENV%
+    WSGIDaemonProcess keystone-public processes=5 threads=1 user=%USER% display-name=%{GROUP} %VIRTUALENV%
     WSGIProcessGroup keystone-public
     WSGIScriptAlias / %KEYSTONE_BIN%/keystone-wsgi-public
     WSGIApplicationGroup %{GLOBAL}
     WSGIPassAuthorization On
-    ErrorLogFormat "%M"
+    <IfVersion >= 2.4>
+      ErrorLogFormat "%{cu}t %M"
+    </IfVersion>
     ErrorLog /var/log/%APACHE_NAME%/keystone.log
     CustomLog /var/log/%APACHE_NAME%/keystone_access.log keystone_combined
     %SSLENGINE%
     %SSLCERTFILE%
     %SSLKEYFILE%
+
+    <Directory %KEYSTONE_BIN%>
+        <IfVersion >= 2.4>
+            Require all granted
+        </IfVersion>
+        <IfVersion < 2.4>
+            Order allow,deny
+            Allow from all
+        </IfVersion>
+    </Directory>
 </VirtualHost>
 
-%SSLLISTEN%<VirtualHost *:443>
-%SSLLISTEN%    %SSLENGINE%
-%SSLLISTEN%    %SSLCERTFILE%
-%SSLLISTEN%    %SSLKEYFILE%
-%SSLLISTEN%    SSLProtocol -all +TLSv1.3 +TLSv1.2
-%SSLLISTEN%</VirtualHost>
+<VirtualHost *:%ADMINPORT%>
+    WSGIDaemonProcess keystone-admin processes=5 threads=1 user=%USER% display-name=%{GROUP} %VIRTUALENV%
+    WSGIProcessGroup keystone-admin
+    WSGIScriptAlias / %KEYSTONE_BIN%/keystone-wsgi-admin
+    WSGIApplicationGroup %{GLOBAL}
+    WSGIPassAuthorization On
+    <IfVersion >= 2.4>
+      ErrorLogFormat "%{cu}t %M"
+    </IfVersion>
+    ErrorLog /var/log/%APACHE_NAME%/keystone.log
+    CustomLog /var/log/%APACHE_NAME%/keystone_access.log keystone_combined
+    %SSLENGINE%
+    %SSLCERTFILE%
+    %SSLKEYFILE%
 
-Alias /identity %KEYSTONE_BIN%/keystone-wsgi-public
+    <Directory %KEYSTONE_BIN%>
+        <IfVersion >= 2.4>
+            Require all granted
+        </IfVersion>
+        <IfVersion < 2.4>
+            Order allow,deny
+            Allow from all
+        </IfVersion>
+    </Directory>
+</VirtualHost>
+
+Alias /identity %PUBLICWSGI%
 <Location /identity>
     SetHandler wsgi-script
     Options +ExecCGI
@@ -35,3 +63,13 @@ Alias /identity %KEYSTONE_BIN%/keystone-wsgi-public
     WSGIApplicationGroup %{GLOBAL}
     WSGIPassAuthorization On
 </Location>
+
+Alias /identity_admin %ADMINWSGI%
+<Location /identity_admin>
+    SetHandler wsgi-script
+    Options +ExecCGI
+
+    WSGIProcessGroup keystone-admin
+    WSGIApplicationGroup %{GLOBAL}
+    WSGIPassAuthorization On
+</Location>

files/apache-neutron.template

@@ -1,37 +0,0 @@
-Listen %PUBLICPORT%
-LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\" %D(us)" neutron_combined
-
-<Directory %NEUTRON_BIN%>
-    Require all granted
-</Directory>
-
-<VirtualHost *:%PUBLICPORT%>
-    WSGIDaemonProcess neutron-server processes=%APIWORKERS% threads=1 user=%USER% display-name=%{GROUP} %VIRTUALENV%
-    WSGIProcessGroup neutron-server
-    WSGIScriptAlias / %NEUTRON_BIN%/neutron-api
-    WSGIApplicationGroup %{GLOBAL}
-    WSGIPassAuthorization On
-    ErrorLogFormat "%M"
-    ErrorLog /var/log/%APACHE_NAME%/neutron.log
-    CustomLog /var/log/%APACHE_NAME%/neutron_access.log neutron_combined
-    %SSLENGINE%
-    %SSLCERTFILE%
-    %SSLKEYFILE%
-</VirtualHost>
-
-
-%SSLLISTEN%<VirtualHost *:443>
-%SSLLISTEN%    %SSLENGINE%
-%SSLLISTEN%    %SSLCERTFILE%
-%SSLLISTEN%    %SSLKEYFILE%
-%SSLLISTEN%    SSLProtocol -all +TLSv1.3 +TLSv1.2
-%SSLLISTEN%</VirtualHost>
-
-Alias /networking %NEUTRON_BIN%/neutron-api
-<Location /networking>
-    SetHandler wsgi-script
-    Options +ExecCGI
-    WSGIProcessGroup neutron-server
-    WSGIApplicationGroup %{GLOBAL}
-    WSGIPassAuthorization On
-</Location>

files/apache-nova-api.template

@@ -7,7 +7,7 @@ Listen %PUBLICPORT%
     WSGIApplicationGroup %{GLOBAL}
     WSGIPassAuthorization On
     <IfVersion >= 2.4>
-      ErrorLogFormat "%M"
+      ErrorLogFormat "%{cu}t %M"
     </IfVersion>
     ErrorLog /var/log/%APACHE_NAME%/nova-api.log
     %SSLENGINE%

files/apache-nova-ec2-api.template

@@ -0,0 +1,16 @@
+Listen %PUBLICPORT%
+
+<VirtualHost *:%PUBLICPORT%>
+    WSGIDaemonProcess nova-ec2-api processes=%APIWORKERS% threads=1 user=%USER% display-name=%{GROUP} %VIRTUALENV%
+    WSGIProcessGroup nova-ec2-api
+    WSGIScriptAlias / %PUBLICWSGI%
+    WSGIApplicationGroup %{GLOBAL}
+    WSGIPassAuthorization On
+    <IfVersion >= 2.4>
+      ErrorLogFormat "%{cu}t %M"
+    </IfVersion>
+    ErrorLog /var/log/%APACHE_NAME%/nova-ec2-api.log
+    %SSLENGINE%
+    %SSLCERTFILE%
+    %SSLKEYFILE%
+</VirtualHost>

files/apache-nova-metadata.template

@@ -1,25 +0,0 @@
-Listen %PUBLICPORT%
-
-<VirtualHost *:%PUBLICPORT%>
-    WSGIDaemonProcess nova-metadata processes=%APIWORKERS% threads=1 user=%USER% display-name=%{GROUP} %VIRTUALENV%
-    WSGIProcessGroup nova-metadata
-    WSGIScriptAlias / %PUBLICWSGI%
-    WSGIApplicationGroup %{GLOBAL}
-    WSGIPassAuthorization On
-    <IfVersion >= 2.4>
-      ErrorLogFormat "%M"
-    </IfVersion>
-    ErrorLog /var/log/%APACHE_NAME%/nova-metadata.log
-    %SSLENGINE%
-    %SSLCERTFILE%
-    %SSLKEYFILE%
-</VirtualHost>
-
-Alias /metadata %PUBLICWSGI%
-<Location /metadata>
-    SetHandler wsgi-script
-    Options +ExecCGI
-    WSGIProcessGroup nova-metadata
-    WSGIApplicationGroup %{GLOBAL}
-    WSGIPassAuthorization On
-</Location>

files/apache-placement-api.template

@@ -1,27 +0,0 @@
-# NOTE(sbauza): This virtualhost is only here because some directives can
-# only be set by a virtualhost or server context, so that's why the port is not bound.
-# TODO(sbauza): Find a better way to identify a free port that is not corresponding to an existing
-# vhost.
-<VirtualHost *:8780>
-    WSGIDaemonProcess placement-api processes=%APIWORKERS% threads=1 user=%USER% display-name=%{GROUP} %VIRTUALENV%
-    WSGIProcessGroup placement-api
-    WSGIScriptAlias / %PUBLICWSGI%
-    WSGIApplicationGroup %{GLOBAL}
-    WSGIPassAuthorization On
-    <IfVersion >= 2.4>
-      ErrorLogFormat "%M"
-    </IfVersion>
-    ErrorLog /var/log/%APACHE_NAME%/placement-api.log
-    %SSLENGINE%
-    %SSLCERTFILE%
-    %SSLKEYFILE%
-</VirtualHost>
-
-Alias /placement %PUBLICWSGI%
-<Location /placement>
-    SetHandler wsgi-script
-    Options +ExecCGI
-    WSGIProcessGroup placement-api
-    WSGIApplicationGroup %{GLOBAL}
-    WSGIPassAuthorization On
-</Location>

files/apts

@@ -0,0 +1 @@
+debs/

files/debs/ceilometer-collector

@@ -0,0 +1,6 @@
+python-pymongo #NOPRIME
+mongodb-server #NOPRIME
+libnspr4-dev
+pkg-config
+libxml2-dev
+libxslt-dev

files/debs/cinder

@@ -1,4 +1,6 @@
+tgt # NOPRIME
 lvm2
 qemu-utils
-tgt # NOPRIME
-thin-provisioning-tools
+libpq-dev
+open-iscsi
+open-iscsi-utils # Deprecated since quantal dist:precise

files/debs/devlibs

@@ -0,0 +1,7 @@
+libffi-dev  # pyOpenSSL
+libmysqlclient-dev  # MySQL-python
+libpq-dev  # psycopg2
+libssl-dev  # pyOpenSSL
+libxml2-dev  # lxml
+libxslt1-dev  # lxml
+python-dev  # pyOpenSSL

files/debs/dstat

@@ -1,2 +1 @@
-dstat # dist:bionic
-pcp
+dstat

files/debs/general

@@ -1,39 +1,31 @@
-apache2
-apache2-dev
-bc
+bridge-utils
+screen
+unzip
+wget
+psmisc
 bsdmainutils
-curl
-default-jre-headless  # NOPRIME
-g++
-gawk
 gcc
-gettext  # used for compiling message catalogs
+g++
 git
 graphviz # needed for docs
-iputils-ping
-libapache2-mod-proxy-uwsgi
-libffi-dev # for pyOpenSSL
-libjpeg-dev # Pillow 3.0.0
-libpcre3-dev # for python-pcre
-libpq-dev  # psycopg2
-libssl-dev # for pyOpenSSL
-libsystemd-dev # for systemd-python
-libxml2-dev  # lxml
-libxslt1-dev  # lxml
-libyaml-dev
 lsof # useful when debugging
 openssh-server
 openssl
-pkg-config
-psmisc
-python3-dev
-python3-pip
-python3-systemd
-python3-venv
-tar
+iputils-ping
+wget
+curl
 tcpdump
-unzip
+tar
+python-dev
+python2.7
+python-gdbm # needed for testr
+bc
+libyaml-dev
+libffi-dev # for pyOpenSSL
+libssl-dev # for pyOpenSSL
+libxml2-dev  # lxml
+libxslt1-dev  # lxml
+gettext  # used for compiling message catalogs
+openjdk-7-jre-headless  # NOPRIME
+pkg-config
 uuid-runtime
-wget
-wget
-zlib1g-dev

files/debs/glance

@@ -0,0 +1,6 @@
+libmysqlclient-dev
+libpq-dev
+libssl-dev
+libxml2-dev
+libxslt1-dev
+zlib1g-dev

files/debs/heat

@@ -0,0 +1 @@
+gettext # dist:trusty

files/debs/horizon

@@ -1,2 +1,3 @@
 apache2  # NOPRIME
 libapache2-mod-wsgi  # NOPRIME
+libpcre3-dev  # pyScss

files/debs/ironic

@@ -0,0 +1,21 @@
+# apparmor is an undeclared dependency for docker on ubuntu: https://github.com/docker/docker/issues/9745
+apparmor
+docker.io
+ipmitool
+iptables
+ipxe
+libguestfs0
+libvirt-bin
+open-iscsi
+openssh-client
+openvswitch-switch
+openvswitch-datapath-dkms
+python-libguestfs
+python-libvirt
+qemu
+qemu-kvm
+qemu-utils
+sgabios
+syslinux
+tftpd-hpa
+xinetd

files/debs/keystone

@@ -1,6 +1,7 @@
-libkrb5-dev
+sqlite3
+python-mysqldb
+python-mysql.connector
 libldap2-dev
 libsasl2-dev
+libkrb5-dev
 memcached
-python3-mysqldb
-sqlite3

files/debs/ldap

@@ -1,3 +1,3 @@
 ldap-utils
-python3-ldap
 slapd
+python-ldap

files/debs/n-api

@@ -0,0 +1 @@
+fping

files/debs/n-cpu

@@ -1,11 +1,8 @@
-cryptsetup
-dosfstools
-genisoimage
-gir1.2-libosinfo-1.0
-lvm2 # NOPRIME
-netcat-openbsd
-open-iscsi
-python3-guestfs # NOPRIME
 qemu-utils
-sg3-utils
+lvm2 # NOPRIME
+open-iscsi
+genisoimage
 sysfsutils
+sg3-utils
+python-guestfs # NOPRIME
+cryptsetup

files/debs/neutron

@@ -1,16 +1,17 @@
 acl
-dnsmasq-base
-dnsmasq-utils # for dhcp_release
 ebtables
-haproxy # to serve as metadata proxy inside router/dhcp namespaces
 iptables
-iputils-arping
 iputils-ping
+iputils-arping
+libmysqlclient-dev
 mysql-server #NOPRIME
-postgresql-server-dev-all
-python3-mysqldb
-rabbitmq-server # NOPRIME
-radvd # NOPRIME
-sqlite3
 sudo
+postgresql-server-dev-all
+python-mysqldb
+python-mysql.connector
+dnsmasq-base
+dnsmasq-utils # for dhcp_release only available in dist:precise
+rabbitmq-server # NOPRIME
+sqlite3
 vlan
+radvd # NOPRIME

files/debs/neutron-l3

@@ -1,3 +0,0 @@
-conntrack
-conntrackd
-keepalived

files/debs/nova

@@ -1,21 +1,28 @@
+dnsmasq-base
+dnsmasq-utils # for dhcp_release
 conntrack
-curl
-ebtables
-genisoimage # required for config_drive
-iptables
-iputils-arping
 kpartx
-libjs-jquery-tablesorter # Needed for coverage html reports
-libvirt-clients # NOPRIME
-libvirt-daemon-system # NOPRIME
-libvirt-dev # NOPRIME
-mysql-server # NOPRIME
 parted
-pm-utils
-python3-mysqldb
-qemu-kvm # NOPRIME
-rabbitmq-server # NOPRIME
-socat # used by ajaxterm
+iputils-arping
+libmysqlclient-dev
+mysql-server # NOPRIME
+python-mysqldb
+python-mysql.connector
+libxml2-dev # needed for building lxml
+libxslt1-dev
+gawk
+iptables
+ebtables
 sqlite3
 sudo
+qemu-kvm # NOPRIME
+qemu # dist:wheezy,jessie NOPRIME
+libvirt-bin # NOPRIME
+libvirt-dev # NOPRIME
+pm-utils
+libjs-jquery-tablesorter # Needed for coverage html reports
 vlan
+curl
+genisoimage # required for config_drive
+rabbitmq-server # NOPRIME
+socat # used by ajaxterm

files/debs/os-brick

@@ -1,3 +0,0 @@
-lsscsi
-open-iscsi
-open-iscsi-utils # Deprecated since quantal dist:precise

files/debs/ovn

@@ -1,3 +0,0 @@
-ovn-central
-ovn-controller-vtep
-ovn-host

files/debs/q-agt

@@ -1 +0,0 @@
-neutron-agent

files/debs/q-agt

@@ -0,0 +1 @@
+ipset

files/debs/q-l3

@@ -1 +0,0 @@
-neutron-l3