diff --git a/.gitignore b/.gitignore
index 2778a65c89..956e13e21c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,9 +1,13 @@
*~
.*.sw?
*.log
-*.log.[1-9]
+*-log
+*.log.*
+*-log.*
*.pem
+*.pyc
.localrc.auto
+.localrc.password
.prereqs
.tox
.stackenv
@@ -11,16 +15,26 @@ 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*
-local.conf
+files/ironic-inspector*
+files/etcd*
+^local.conf
local.sh
localrc
proto
shocco
src
stack-screenrc
+userrc_early
+AUTHORS
+ChangeLog
diff --git a/.zuul.yaml b/.zuul.yaml
new file mode 100644
index 0000000000..9aafcdbb84
--- /dev/null
+++ b/.zuul.yaml
@@ -0,0 +1,700 @@
+- nodeset:
+ name: openstack-single-node
+ nodes:
+ - name: controller
+ label: ubuntu-xenial
+ groups:
+ - name: tempest
+ nodes:
+ - controller
+
+- nodeset:
+ name: openstack-single-node-bionic
+ nodes:
+ - name: controller
+ label: ubuntu-bionic
+ groups:
+ - name: tempest
+ nodes:
+ - controller
+
+- nodeset:
+ name: openstack-single-node-xenial
+ nodes:
+ - name: controller
+ label: ubuntu-xenial
+ groups:
+ - name: tempest
+ nodes:
+ - controller
+
+- nodeset:
+ name: devstack-single-node-centos-7
+ nodes:
+ - name: controller
+ label: centos-7
+ groups:
+ - name: tempest
+ nodes:
+ - controller
+
+- nodeset:
+ name: devstack-single-node-opensuse-150
+ nodes:
+ - name: controller
+ label: opensuse-150
+ groups:
+ - name: tempest
+ nodes:
+ - controller
+
+- nodeset:
+ name: devstack-single-node-fedora-latest
+ nodes:
+ - name: controller
+ label: fedora-28
+ groups:
+ - name: tempest
+ nodes:
+ - controller
+
+- nodeset:
+ name: openstack-two-node
+ nodes:
+ - name: controller
+ label: ubuntu-xenial
+ - name: compute1
+ label: ubuntu-xenial
+ groups:
+ # Node where tests are executed and test results collected
+ - name: tempest
+ nodes:
+ - controller
+ # Nodes running the compute service
+ - name: compute
+ nodes:
+ - controller
+ - compute1
+ # Nodes that are not the controller
+ - name: subnode
+ nodes:
+ - compute1
+ # Switch node for multinode networking setup
+ - name: switch
+ nodes:
+ - controller
+ # Peer nodes for multinode networking setup
+ - name: peers
+ nodes:
+ - compute1
+
+- nodeset:
+ name: openstack-two-node-bionic
+ nodes:
+ - name: controller
+ label: ubuntu-bionic
+ - name: compute1
+ label: ubuntu-bionic
+ groups:
+ # Node where tests are executed and test results collected
+ - name: tempest
+ nodes:
+ - controller
+ # Nodes running the compute service
+ - name: compute
+ nodes:
+ - controller
+ - compute1
+ # Nodes that are not the controller
+ - name: subnode
+ nodes:
+ - compute1
+ # Switch node for multinode networking setup
+ - name: switch
+ nodes:
+ - controller
+ # Peer nodes for multinode networking setup
+ - name: peers
+ nodes:
+ - compute1
+
+- nodeset:
+ name: openstack-two-node-xenial
+ nodes:
+ - name: controller
+ label: ubuntu-xenial
+ - name: compute1
+ label: ubuntu-xenial
+ groups:
+ # Node where tests are executed and test results collected
+ - name: tempest
+ nodes:
+ - controller
+ # Nodes running the compute service
+ - name: compute
+ nodes:
+ - controller
+ - compute1
+ # Nodes that are not the controller
+ - name: subnode
+ nodes:
+ - compute1
+ # Switch node for multinode networking setup
+ - name: switch
+ nodes:
+ - controller
+ # Peer nodes for multinode networking setup
+ - name: peers
+ nodes:
+ - compute1
+
+- job:
+ name: devstack-base
+ parent: multinode
+ abstract: true
+ description: |
+ Base abstract Devstack job.
+
+ Defines plays and base variables, but it does not include any project
+ and it does not run any service by default. This is a common base for
+ all single Devstack jobs, single or multinode.
+ Variables are defined in job.vars, which is what is then used by single
+ node jobs and by multi node jobs for the controller, as well as in
+ job.group-vars.peers, which is what is used by multi node jobs for subnode
+ nodes (everything but the controller).
+ required-projects:
+ - git.openstack.org/openstack-dev/devstack
+ roles:
+ - zuul: git.openstack.org/openstack-infra/devstack-gate
+ - zuul: git.openstack.org/openstack-infra/openstack-zuul-jobs
+ vars:
+ devstack_localrc:
+ DATABASE_PASSWORD: secretdatabase
+ RABBIT_PASSWORD: secretrabbit
+ ADMIN_PASSWORD: secretadmin
+ SERVICE_PASSWORD: secretservice
+ NETWORK_GATEWAY: 10.1.0.1
+ FIXED_RANGE: 10.1.0.0/20
+ IPV4_ADDRS_SAFE_TO_USE: 10.1.0.0/20
+ FLOATING_RANGE: 172.24.5.0/24
+ PUBLIC_NETWORK_GATEWAY: 172.24.5.1
+ LOGFILE: /opt/stack/logs/devstacklog.txt
+ LOG_COLOR: false
+ VERBOSE: true
+ VERBOSE_NO_TIMESTAMP: true
+ NOVNC_FROM_PACKAGE: true
+ ERROR_ON_CLONE: true
+ # Gate jobs can't deal with nested virt. Disable it.
+ LIBVIRT_TYPE: qemu
+ devstack_services:
+ # Ignore any default set by devstack. Emit a "disable_all_services".
+ base: false
+ zuul_copy_output:
+ '{{ devstack_conf_dir }}/local.conf': logs
+ '{{ devstack_conf_dir }}/localrc': logs
+ '{{ devstack_conf_dir }}/.localrc.auto': logs
+ '{{ devstack_conf_dir }}/.stackenv': logs
+ '{{ devstack_log_dir }}/dstat-csv.log': logs
+ '{{ devstack_log_dir }}/devstacklog.txt': logs
+ '{{ devstack_log_dir }}/devstacklog.txt.summary': logs
+ '{{ devstack_full_log}}': logs
+ '{{ stage_dir }}/verify_tempest_conf.log': logs
+ '{{ stage_dir }}/apache': logs
+ '{{ stage_dir }}/apache_config': logs
+ '{{ stage_dir }}/etc': logs
+ /var/log/rabbitmq: logs
+ /var/log/postgresql: logs
+ /var/log/mysql.err: logs
+ /var/log/mysql.log: logs
+ /var/log/libvirt: logs
+ /etc/sudoers: logs
+ /etc/sudoers.d: logs
+ '{{ stage_dir }}/iptables.txt': logs
+ '{{ stage_dir }}/df.txt': logs
+ '{{ stage_dir }}/pip2-freeze.txt': logs
+ '{{ stage_dir }}/pip3-freeze.txt': logs
+ '{{ stage_dir }}/dpkg-l.txt': logs
+ '{{ stage_dir }}/rpm-qa.txt': logs
+ '{{ stage_dir }}/core': logs
+ '{{ stage_dir }}/listen53.txt': logs
+ '{{ stage_dir }}/deprecations.log': logs
+ /var/log/ceph: logs
+ /var/log/openvswitch: logs
+ /var/log/glusterfs: logs
+ /etc/glusterfs/glusterd.vol: logs
+ /etc/resolv.conf: logs
+ /var/log/unbound.log: logs
+ extensions_to_txt:
+ conf: true
+ log: true
+ localrc: true
+ stackenv: true
+ auto: true
+ group-vars:
+ subnode:
+ devstack_localrc:
+ DATABASE_PASSWORD: secretdatabase
+ RABBIT_PASSWORD: secretrabbit
+ ADMIN_PASSWORD: secretadmin
+ SERVICE_PASSWORD: secretservice
+ NETWORK_GATEWAY: 10.1.0.1
+ FIXED_RANGE: 10.1.0.0/20
+ IPV4_ADDRS_SAFE_TO_USE: 10.1.0.0/20
+ FLOATING_RANGE: 172.24.5.0/24
+ PUBLIC_NETWORK_GATEWAY: 172.24.5.1
+ LOGFILE: /opt/stack/logs/devstacklog.txt
+ LOG_COLOR: false
+ VERBOSE: true
+ VERBOSE_NO_TIMESTAMP: true
+ NOVNC_FROM_PACKAGE: true
+ ERROR_ON_CLONE: true
+ LIBVIRT_TYPE: qemu
+ devstack_services:
+ base: false
+ pre-run: playbooks/pre.yaml
+ run: playbooks/devstack.yaml
+ post-run: playbooks/post.yaml
+ irrelevant-files:
+ # Documentation related
+ - ^.*\.rst$
+ - ^api-ref/.*$
+ - ^doc/.*$
+ - ^releasenotes/.*$
+ # Translations
+ - ^.*/locale/.*po$
+
+- job:
+ name: devstack-minimal
+ parent: devstack-base
+ description: |
+ Minimal devstack base job, intended for use by jobs that need
+ less than the normal minimum set of required-projects.
+ nodeset: openstack-single-node-bionic
+ required-projects:
+ - git.openstack.org/openstack/requirements
+ vars:
+ devstack_localrc:
+ # Multinode specific settings
+ SERVICE_HOST: "{{ hostvars['controller']['nodepool']['private_ipv4'] }}"
+ HOST_IP: "{{ hostvars['controller']['nodepool']['private_ipv4'] }}"
+ PUBLIC_BRIDGE_MTU: '{{ external_bridge_mtu }}'
+ devstack_services:
+ # Shared services
+ dstat: true
+ etcd3: true
+ mysql: true
+ peakmem_tracker: true
+ rabbit: true
+ group-vars:
+ subnode:
+ devstack_services:
+ # Shared services
+ dstat: true
+ peakmem_tracker: true
+ devstack_localrc:
+ # Multinode specific settings
+ HOST_IP: "{{ hostvars[inventory_hostname]['nodepool']['private_ipv4'] }}"
+ SERVICE_HOST: "{{ hostvars['controller']['nodepool']['private_ipv4'] }}"
+ PUBLIC_BRIDGE_MTU: '{{ external_bridge_mtu }}'
+ # Subnode specific settings
+ DATABASE_TYPE: mysql
+ RABBIT_HOST: "{{ hostvars['controller']['nodepool']['private_ipv4'] }}"
+ DATABASE_HOST: "{{ hostvars['controller']['nodepool']['private_ipv4'] }}"
+
+
+- job:
+ name: devstack
+ parent: devstack-minimal
+ description: |
+ Base devstack job for integration gate.
+
+ This base job can be used for single node and multinode devstack jobs.
+
+ With a single node nodeset, this job sets up an "all-in-one" (aio)
+ devstack with the seven OpenStack services included in the devstack tree:
+ keystone, glance, cinder, neutron, nova, placement, and swift.
+
+ With a two node nodeset, this job sets up an aio + compute node.
+ The controller can be customised using host-vars.controller, the
+ sub-nodes can be customised using group-vars.subnode.
+
+ Descendent jobs can enable / disable services, add devstack configuration
+ options, enable devstack plugins, configure log files or directories to be
+ transferred to the log server.
+
+ The job assumes that there is only one controller node. The number of
+ subnodes can be scaled up seamlessly by setting a custom nodeset in
+ job.nodeset.
+
+ The run playbook consists of a single role, so it can be easily rewritten
+ and extended.
+ required-projects:
+ - git.openstack.org/openstack/cinder
+ - git.openstack.org/openstack/glance
+ - git.openstack.org/openstack/keystone
+ - git.openstack.org/openstack/neutron
+ - git.openstack.org/openstack/nova
+ - git.openstack.org/openstack/placement
+ - git.openstack.org/openstack/swift
+ timeout: 7200
+ vars:
+ devstack_localrc:
+ # Common OpenStack services settings
+ SWIFT_REPLICAS: 1
+ SWIFT_START_ALL_SERVICES: false
+ SWIFT_HASH: 1234123412341234
+ CINDER_PERIODIC_INTERVAL: 10
+ DEBUG_LIBVIRT_COREDUMPS: true
+ NOVA_VNC_ENABLED: true
+ VNCSERVER_LISTEN: 0.0.0.0
+ VNCSERVER_PROXYCLIENT_ADDRESS: $HOST_IP
+ devstack_local_conf:
+ post-config:
+ $NEUTRON_CONF:
+ DEFAULT:
+ global_physnet_mtu: '{{ external_bridge_mtu }}'
+ devstack_services:
+ # Core services enabled for this branch.
+ # This list replaces the test-matrix.
+ # Shared services
+ dstat: true
+ etcd3: true
+ mysql: true
+ peakmem_tracker: true
+ rabbit: true
+ tls-proxy: true
+ # Keystone services
+ key: true
+ # Glance services
+ g-api: true
+ g-reg: true
+ # Nova services
+ n-api: true
+ n-api-meta: true
+ n-cauth: true
+ n-cond: true
+ n-cpu: true
+ n-novnc: true
+ n-obj: true
+ n-sch: true
+ placement-api: true
+ # Neutron services
+ # We need to keep using the neutron-legacy based services for
+ # now until all issues with the new lib/neutron code are solved
+ q-agt: true
+ q-dhcp: true
+ q-l3: true
+ q-meta: true
+ q-metering: true
+ q-svc: true
+ # neutron-api: true
+ # neutron-agent: true
+ # neutron-dhcp: true
+ # neutron-l3: true
+ # neutron-metadata-agent: true
+ # neutron-metering: true
+ # Swift services
+ s-account: true
+ s-container: true
+ s-object: true
+ s-proxy: true
+ # Cinder services
+ c-api: true
+ c-bak: true
+ c-sch: true
+ c-vol: true
+ cinder: true
+ # Services we don't need.
+ # This section is not really needed, it's for readability.
+ horizon: false
+ tempest: false
+ # Test matrix emits ceilometer but ceilomenter is not installed in the
+ # integrated gate, so specifying the services has not effect.
+ # ceilometer-*: false
+ group-vars:
+ subnode:
+ devstack_services:
+ # Core services enabled for this branch.
+ # This list replaces the test-matrix.
+ # Shared services
+ dstat: true
+ peakmem_tracker: true
+ tls-proxy: true
+ # Nova services
+ n-cpu: true
+ placement-client: true
+ # Neutron services
+ neutron-agent: true
+ # Cinder services
+ c-bak: true
+ c-vol: true
+ # Services we don't run at all on subnode.
+ # This section is not really needed, it's for readability.
+ # keystone: false
+ # s-*: false
+ horizon: false
+ tempest: false
+ # Test matrix emits ceilometer but ceilomenter is not installed in the
+ # integrated gate, so specifying the services has not effect.
+ # ceilometer-*: false
+ devstack_localrc:
+ # Subnode specific settings
+ GLANCE_HOSTPORT: "{{ hostvars['controller']['nodepool']['private_ipv4'] }}:9292"
+ Q_HOST: "{{ hostvars['controller']['nodepool']['private_ipv4'] }}"
+ NOVA_VNC_ENABLED: true
+ VNCSERVER_LISTEN: 0.0.0.0
+ VNCSERVER_PROXYCLIENT_ADDRESS: $HOST_IP
+
+- job:
+ name: devstack-ipv6
+ parent: devstack
+ description: |
+ Devstack single node job for integration gate with IPv6.
+ vars:
+ devstack_localrc:
+ SERVICE_IP_VERSION: 6
+ SERVICE_HOST: ""
+ # IPv6 and certificates known issue with python2
+ # https://bugs.launchpad.net/devstack/+bug/1794929
+ USE_PYTHON3: true
+
+- job:
+ name: devstack-xenial
+ parent: devstack
+ nodeset: openstack-single-node-xenial
+ description: |
+ Simple singlenode test to verify functionality on devstack
+ side running on Xenial.
+
+- job:
+ name: devstack-multinode
+ parent: devstack
+ nodeset: openstack-two-node-bionic
+ description: |
+ Simple multinode test to verify multinode functionality on devstack side.
+ This is not meant to be used as a parent job.
+
+- job:
+ name: devstack-multinode-xenial
+ parent: devstack
+ nodeset: openstack-two-node-xenial
+ description: |
+ Simple multinode test to verify multinode functionality on devstack
+ side running on Xenial.
+ This is not meant to be used as a parent job.
+
+# NOTE(ianw) Platform tests have traditionally been non-voting because
+# we often have to rush things through devstack to stabilise the gate,
+# and these platforms don't have the round-the-clock support to avoid
+# becoming blockers in that situation.
+- job:
+ name: devstack-platform-centos-7
+ parent: tempest-full
+ description: Centos 7 platform test
+ nodeset: devstack-single-node-centos-7
+ voting: false
+
+- job:
+ name: devstack-platform-opensuse-150
+ parent: tempest-full
+ description: openSUSE 15.0 platform test
+ nodeset: devstack-single-node-opensuse-150
+ voting: false
+
+- job:
+ name: devstack-platform-fedora-latest
+ parent: tempest-full
+ description: Fedora latest platform test
+ nodeset: devstack-single-node-fedora-latest
+ voting: false
+
+- job:
+ name: devstack-platform-xenial
+ parent: tempest-full
+ description: Ubuntu Xenial platform test
+ nodeset: openstack-single-node-xenial
+ voting: false
+
+- job:
+ name: devstack-tox-base
+ parent: devstack
+ description: |
+ Base job for devstack-based functional tests that use tox.
+
+ This job is not intended to be run directly. It's just here
+ for organizational purposes for devstack-tox-functional and
+ devstack-tox-functional-consumer.
+ post-run: playbooks/tox/post.yaml
+ vars:
+ tox_envlist: functional
+ tox_install_siblings: false
+
+- job:
+ name: devstack-tox-functional
+ parent: devstack-tox-base
+ description: |
+ Base job for devstack-based functional tests that use tox.
+
+ Runs devstack, then runs the tox ``functional`` environment,
+ then collects tox/testr build output like normal tox jobs.
+
+ Turns off tox sibling installation. Projects may be involved
+ in the devstack deployment and so may be in the required-projects
+ list, but may not want to test against master of the other
+ projects in their tox env. Child jobs can set tox_install_siblings
+ to True to re-enable sibling processing.
+ run: playbooks/tox/run-both.yaml
+
+- job:
+ name: devstack-tox-functional-consumer
+ parent: devstack
+ description: |
+ Base job for devstack-based functional tests for projects that
+ consume the devstack cloud.
+
+ This base job should only be used by projects that are not involved
+ in the devstack deployment step, but are instead projects that are using
+ devstack to get a cloud against which they can test things.
+
+ Runs devstack in pre-run, then runs the tox ``functional`` environment,
+ then collects tox/testr build output like normal tox jobs.
+
+ Turns off tox sibling installation. Projects may be involved
+ in the devstack deployment and so may be in the required-projects
+ list, but may not want to test against master of the other
+ projects in their tox env. Child jobs can set tox_install_siblings
+ to True to re-enable sibling processing.
+ pre-run:
+ - playbooks/devstack.yaml
+ - playbooks/tox/pre.yaml
+ run: playbooks/tox/run.yaml
+
+- job:
+ name: devstack-unit-tests
+ description: |
+ Runs unit tests on devstack project.
+
+ It runs ``run_tests.sh``.
+ pre-run: playbooks/unit-tests/pre.yaml
+ run: playbooks/unit-tests/run.yaml
+
+- project:
+ templates:
+ - integrated-gate
+ - integrated-gate-py35
+ - publish-openstack-docs-pti
+ check:
+ jobs:
+ - devstack
+ - devstack-xenial
+ - devstack-ipv6:
+ voting: false
+ - devstack-platform-centos-7
+ - devstack-platform-opensuse-150
+ - devstack-platform-fedora-latest
+ - devstack-platform-xenial
+ - devstack-multinode
+ - devstack-multinode-xenial
+ - devstack-unit-tests
+ - openstack-tox-bashate
+ - ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa:
+ voting: false
+ - swift-dsvm-functional:
+ voting: false
+ irrelevant-files:
+ - ^.*\.rst$
+ - ^doc/.*$
+ - neutron-grenade:
+ irrelevant-files:
+ - ^.*\.rst$
+ - ^doc/.*$
+ - neutron-grenade-multinode:
+ irrelevant-files:
+ - ^.*\.rst$
+ - ^doc/.*$
+ - neutron-tempest-linuxbridge:
+ irrelevant-files:
+ - ^.*\.rst$
+ - ^doc/.*$
+ - tempest-multinode-full:
+ voting: false
+ irrelevant-files:
+ - ^.*\.rst$
+ - ^doc/.*$
+ gate:
+ jobs:
+ - devstack
+ - devstack-xenial
+ - devstack-multinode
+ - devstack-multinode-xenial
+ - devstack-unit-tests
+ - openstack-tox-bashate
+ - neutron-grenade-multinode:
+ irrelevant-files:
+ - ^.*\.rst$
+ - ^doc/.*$
+ - neutron-tempest-linuxbridge:
+ irrelevant-files:
+ - ^.*\.rst$
+ - ^doc/.*$
+ - neutron-grenade:
+ irrelevant-files:
+ - ^.*\.rst$
+ - ^doc/.*$
+ # Please add a note on each job and conditions for the job not
+ # being experimental any more, so we can keep this list somewhat
+ # pruned.
+ #
+ # * nova-cells-v1: maintained by nova for cells v1 (nova-cells service);
+ # it's in experimental here (and in nova) for testing cells v1
+ # changes to devstack w/o gating on it for all devstack changes.
+ # * nova-next: maintained by nova for unreleased/undefaulted
+ # things like cellsv2 and placement-api
+ # * neutron-fullstack-with-uwsgi: maintained by neutron for fullstack test
+ # when neutron-api is served by uwsgi, it's in exprimental for testing.
+ # the next cycle we can remove this job if things turn out to be
+ # stable enough.
+ # * neutron-functional-with-uwsgi: maintained by neutron for functional
+ # test. Next cycle we can remove this one if things turn out to be
+ # stable engouh with uwsgi.
+ # * neutron-tempest-with-uwsgi: maintained by neutron for tempest test.
+ # Next cycle we can remove this if everything run out stable enough.
+
+ experimental:
+ jobs:
+ - nova-cells-v1:
+ irrelevant-files:
+ - ^.*\.rst$
+ - ^doc/.*$
+ - nova-next
+ - neutron-fullstack-with-uwsgi
+ - neutron-functional-with-uwsgi
+ - neutron-tempest-with-uwsgi
+ - devstack-plugin-ceph-tempest:
+ irrelevant-files:
+ - ^.*\.rst$
+ - ^doc/.*$
+ - devstack-plugin-ceph-tempest-py3:
+ irrelevant-files:
+ - ^.*\.rst$
+ - ^doc/.*$
+ - neutron-tempest-dvr:
+ irrelevant-files:
+ - ^.*\.rst$
+ - ^doc/.*$
+ - legacy-tempest-dsvm-neutron-dvr-multinode-full:
+ irrelevant-files:
+ - ^.*\.rst$
+ - ^doc/.*$
+ - neutron-tempest-dvr-ha-multinode-full:
+ irrelevant-files:
+ - ^.*\.rst$
+ - ^doc/.*$
+ - legacy-tempest-dsvm-lvm-multibackend:
+ irrelevant-files:
+ - ^.*\.rst$
+ - ^doc/.*$
+ - tempest-pg-full:
+ irrelevant-files:
+ - ^.*\.rst$
+ - ^doc/.*$
diff --git a/HACKING.rst b/HACKING.rst
index a40af54b45..3853eed9a1 100644
--- a/HACKING.rst
+++ b/HACKING.rst
@@ -20,7 +20,7 @@ in `How To Contribute`__ in the OpenStack wiki. `DevStack's LaunchPad project`_
contains the usual links for blueprints, bugs, etc.
__ contribute_
-.. _contribute: http://docs.openstack.org/infra/manual/developers.html
+.. _contribute: https://docs.openstack.org/infra/manual/developers.html
__ lp_
.. _lp: https://launchpad.net/~devstack
@@ -47,12 +47,7 @@ The DevStack repo generally keeps all of the primary scripts at the root
level.
``doc`` - Contains the Sphinx source for the documentation.
-``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.
+A complete doc build can be run with ``tox -edocs``.
``extras.d`` - Contains the dispatch scripts called by the hooks in
``stack.sh``, ``unstack.sh`` and ``clean.sh``. See :doc:`the plugins
@@ -183,89 +178,6 @@ The complete docs build is also handled with tox -edocs 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
@@ -323,13 +235,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
- throughly unless the official CI has run successfully against it.
+ thoroughly 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
@@ -355,7 +267,7 @@ your change
* **Should this be upstream** -- DevStack generally does not override
default choices provided by projects and attempts to not
- unexpectedly modify behaviour.
+ unexpectedly modify behavior.
* **Context in commit messages** -- DevStack touches many different
areas and reviewers need context around changes to make good
@@ -365,3 +277,26 @@ your change
* **Reviewers** -- please see ``MAINTAINERS.rst`` for a list of people
that should be added to reviews of various sub-systems.
+
+
+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.
diff --git a/MAINTAINERS.rst b/MAINTAINERS.rst
index d3e8c67487..d4968a6051 100644
--- a/MAINTAINERS.rst
+++ b/MAINTAINERS.rst
@@ -45,6 +45,13 @@ Fedora/CentOS/RHEL
Neutron
~~~~~~~
+MidoNet
+~~~~~~~
+
+* Jaume Devesa
+* Ryu Ishimoto
+* YAMAMOTO Takashi
+
OpenDaylight
~~~~~~~~~~~~
@@ -56,11 +63,6 @@ OpenFlow Agent (ofagent)
* YAMAMOTO Takashi
* Fumihiko Kakuma
-Sahara
-~~~~~~
-
-* Sergey Lukjanov
-
Swift
~~~~~
diff --git a/Makefile b/Makefile
index 082aff21d2..970d8009eb 100644
--- a/Makefile
+++ b/Makefile
@@ -13,10 +13,9 @@
# Duplicated from stackrc for now
DEST=/opt/stack
-WHEELHOUSE=$(DEST)/.wheelhouse
all:
- echo "This just saved you from a terrible mistake!"
+ @echo "This just saved you from a terrible mistake!"
# Do Some Work
stack:
@@ -25,9 +24,6 @@ stack:
unstack:
./unstack.sh
-wheels:
- WHEELHOUSE=$(WHEELHOUSE) tools/build-wheels.sh
-
docs:
tox -edocs
@@ -57,7 +53,7 @@ clean:
# Clean out the cache too
realclean: clean
- rm -rf files/cirros*.tar.gz files/Fedora*.qcow2 $(WHEELHOUSE)
+ rm -rf files/cirros*.tar.gz files/Fedora*.qcow2
# Repo stuffs
diff --git a/README.md b/README.md
deleted file mode 100644
index 455e1c69c6..0000000000
--- a/README.md
+++ /dev/null
@@ -1,436 +0,0 @@
-DevStack is a set of scripts and utilities to quickly deploy an OpenStack cloud.
-
-# Goals
-
-* 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?)
-* To make it easier for developers to dive into OpenStack so that they can
- productively contribute without having to understand every part of the
- system at once
-* To make it easy to prototype cross-project features
-* To provide an environment for the OpenStack CI testing on every commit
- to the projects
-
-Read more at http://devstack.org.
-
-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
-
-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 juno OpenStack cloud:
-
- git checkout stable/juno
- ./stack.sh
-
-You can also pick specific OpenStack project releases by setting the appropriate
-`*_BRANCH` variables in the ``localrc`` section of `local.conf` (look in
-`stackrc` for the default set). Usually just before a release there will be
-milestone-proposed branches that need to be tested::
-
- GLANCE_REPO=git://git.openstack.org/openstack/glance.git
- GLANCE_BRANCH=milestone-proposed
-
-# 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
-your VM. To start a dev cloud run the following NOT AS ROOT (see
-**DevStack Execution Environment** below for more on user accounts):
-
- ./stack.sh
-
-When the script finishes executing, you should be able to access OpenStack
-endpoints, like so:
-
-* Horizon: http://myhost/
-* Keystone: http://myhost:5000/v2.0/
-
-We also provide an environment file that you can use to interact with your
-cloud via CLI:
-
- # source openrc file to load your environment with OpenStack CLI creds
- . openrc
- # list instances
- nova list
-
-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
-for disappointment, or worse. Alas, we're all in the virtualization business
-here, so run it in a VM. And take advantage of the snapshot capabilities
-of your hypervisor of choice to reduce testing cycle times. You might even save
-enough time to write one more feature before the next feature freeze...
-
-``stack.sh`` needs to have root access for a lot of tasks, but uses ``sudo``
-for all of those tasks. However, it needs to be not-root for most of its
-work and for all of the OpenStack services. ``stack.sh`` specifically
-does not run if started as root.
-
-This is a recent change (Oct 2013) from the previous behaviour of
-automatically creating a ``stack`` user. Automatically creating
-user accounts is not the right response to running as root, so
-that bit is now an explicit step using ``tools/create-stack-user.sh``.
-Run that (as root!) or just 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
-
-You can override environment variables used in `stack.sh` by creating file
-name `local.conf` with a ``localrc`` section as shown below. It is likely
-that you will need to do this to tweak your networking configuration should
-you need to access your cloud from a different host.
-
- [[local|localrc]]
- VARIABLE=value
-
-See the **Local Configuration** section below for more details.
-
-# 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:
-
- disable_service mysql
- enable_service postgresql
-
-`mysql` is the default database.
-
-# RPC Backend
-
-Multiple RPC backends are available. Currently, this
-includes RabbitMQ (default), Qpid, and ZeroMQ. Your backend of
-choice may be selected via the `localrc` section.
-
-Note that selecting more than one RPC backend will result in a failure.
-
-Example (ZeroMQ):
-
- ENABLED_SERVICES="$ENABLED_SERVICES,-rabbit,-qpid,zeromq"
-
-Example (Qpid):
-
- ENABLED_SERVICES="$ENABLED_SERVICES,-rabbit,-zeromq,qpid"
-
-# Apache Frontend
-
-Apache web server can be enabled for wsgi services that support being deployed
-under HTTPD + mod_wsgi. By default, services that recommend running under
-HTTPD + mod_wsgi are deployed under Apache. To use an alternative deployment
-strategy (e.g. eventlet) for services that support an alternative to HTTPD +
-mod_wsgi set ``ENABLE_HTTPD_MOD_WSGI_SERVICES`` to ``False`` in your
-``local.conf``.
-
-Each service that can be run under HTTPD + mod_wsgi also has an override
-toggle available that can be set in your ``local.conf``.
-
-Keystone is run under HTTPD + mod_wsgi by default.
-
-Example (Keystone):
-
- KEYSTONE_USE_MOD_WSGI="True"
-
-Example (Nova):
-
- NOVA_USE_MOD_WSGI="True"
-
-Example (Swift):
-
- SWIFT_USE_MOD_WSGI="True"
-
-# 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. 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` 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:
-
- disable_all_services
- enable_service key mysql s-proxy s-object s-container s-account
-
-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).
-
-# Swift S3
-
-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`.
-
-Only Swift proxy server is launched in the screen session all other
-services are started in background and managed by `swift-init` tool.
-
-# Neutron
-
-Basic Setup
-
-In order to enable Neutron a single node setup, you'll need the
-following settings in your `local.conf`:
-
- disable_service n-net
- enable_service q-svc
- enable_service q-agt
- enable_service q-dhcp
- enable_service q-l3
- enable_service q-meta
- enable_service q-metering
- # Optional, to enable tempest configuration as part of DevStack
- enable_service tempest
-
-Then run `stack.sh` as normal.
-
-DevStack supports setting specific Neutron configuration flags to the
-service, Open vSwitch plugin and LinuxBridge plugin configuration files.
-To make use of this feature, the settings can be added to ``local.conf``.
-The old ``Q_XXX_EXTRA_XXX_OPTS`` variables are deprecated and will be removed
-in the near future. The ``local.conf`` headers for the replacements are:
-
-* ``Q_SRV_EXTRA_OPTS``:
-
- [[post-config|/$Q_PLUGIN_CONF_FILE]]
- [linuxbridge] # or [ovs]
-
-Example extra config in `local.conf`:
-
- [[post-config|/$Q_PLUGIN_CONF_FILE]]
- [agent]
- tunnel_type=vxlan
- vxlan_udp_port=8472
-
- [[post-config|$NEUTRON_CONF]]
- [DEFAULT]
- tenant_network_type=vxlan
-
-DevStack also supports configuring the Neutron ML2 plugin. The ML2 plugin
-can run with the OVS, LinuxBridge, or Hyper-V agents on compute hosts. This
-is a simple way to configure the ml2 plugin:
-
- # VLAN configuration
- Q_PLUGIN=ml2
- ENABLE_TENANT_VLANS=True
-
- # GRE tunnel configuration
- Q_PLUGIN=ml2
- ENABLE_TENANT_TUNNELS=True
-
- # VXLAN tunnel configuration
- Q_PLUGIN=ml2
- Q_ML2_TENANT_NETWORK_TYPE=vxlan
-
-The above will default in DevStack to using the OVS on each compute host.
-To change this, set the `Q_AGENT` variable to the agent you want to run
-(e.g. linuxbridge).
-
- Variable Name Notes
- ----------------------------------------------------------------------------
- Q_AGENT This specifies which agent to run with the
- ML2 Plugin (Typically either `openvswitch`
- or `linuxbridge`).
- Defaults to `openvswitch`.
- Q_ML2_PLUGIN_MECHANISM_DRIVERS The ML2 MechanismDrivers to load. The default
- is `openvswitch,linuxbridge`.
- Q_ML2_PLUGIN_TYPE_DRIVERS The ML2 TypeDrivers to load. Defaults to
- all available TypeDrivers.
- Q_ML2_PLUGIN_GRE_TYPE_OPTIONS GRE TypeDriver options. Defaults to
- `tunnel_id_ranges=1:1000'.
- Q_ML2_PLUGIN_VXLAN_TYPE_OPTIONS VXLAN TypeDriver options. Defaults to
- `vni_ranges=1001:2000`
- Q_ML2_PLUGIN_VLAN_TYPE_OPTIONS VLAN TypeDriver options. Defaults to none.
-
-# 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
-
-If tempest has been successfully configured, a basic set of smoke
-tests can be run as follows:
-
- $ cd /opt/stack/tempest
- $ 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
-package install includes installing dependences). So tempest won't run
-outside of tox. If you would like to install it add the following to your
-``localrc`` section:
-
- INSTALL_TEMPEST=True
-
-# DevStack on Xenserver
-
-If you would like to use Xenserver as the hypervisor, please refer
-to the instructions in `./tools/xen/README.md`.
-
-# Additional Projects
-
-DevStack has a hook mechanism to call out to a dispatch script at specific
-points in the execution of `stack.sh`, `unstack.sh` and `clean.sh`. This
-allows upper-layer projects, especially those that the lower layer projects
-have no dependency on, to be added to DevStack without modifying the core
-scripts. Tempest is built this way as an example of how to structure the
-dispatch script, see `extras.d/80-tempest.sh`. See `extras.d/README.md`
-for more information.
-
-# Multi-Node Setup
-
-A more interesting setup involves running multiple compute nodes, with Neutron
-networks connecting VMs on different compute nodes.
-You should run at least one "controller node", which should have a `stackrc`
-that includes at least:
-
- disable_service n-net
- enable_service q-svc
- enable_service q-agt
- enable_service q-dhcp
- enable_service q-l3
- enable_service q-meta
- enable_service neutron
-
-You likely want to change your `localrc` section to run a scheduler that
-will balance VMs across hosts:
-
- SCHEDULER=nova.scheduler.filter_scheduler.FilterScheduler
-
-You can then run many compute nodes, each of which should have a `stackrc`
-which includes the following, with the IP address of the above controller node:
-
- ENABLED_SERVICES=n-cpu,rabbit,neutron,q-agt
- SERVICE_HOST=[IP of controller node]
- MYSQL_HOST=$SERVICE_HOST
- RABBIT_HOST=$SERVICE_HOST
- Q_HOST=$SERVICE_HOST
- MATCHMAKER_REDIS_HOST=$SERVICE_HOST
-
-# Multi-Region Setup
-
-We want to setup two devstack (RegionOne and RegionTwo) with shared keystone
-(same users and services) and horizon.
-Keystone and Horizon will be located in RegionOne.
-Full spec is available at:
-https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat.
-
-In RegionOne:
-
- REGION_NAME=RegionOne
-
-In RegionTwo:
-
- disable_service horizon
- KEYSTONE_SERVICE_HOST=
- KEYSTONE_AUTH_HOST=
- REGION_NAME=RegionTwo
-
-# Cells
-
-Cells is a new scaling option with a full spec at:
-http://wiki.openstack.org/blueprint-nova-compute-cells.
-
-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.
-
-
-# Local Configuration
-
-Historically DevStack has used ``localrc`` to contain all local configuration
-and customizations. More and more of the configuration variables available for
-DevStack are passed-through to the individual project configuration files.
-The old mechanism for this required specific code for each file and did not
-scale well. This is handled now by a master local configuration file.
-
-# local.conf
-
-The new config file ``local.conf`` is an extended-INI format that introduces
-a new meta-section header that provides some additional information such
-as a phase name and destination config filename:
-
- [[ | ]]
-
-where ```` is one of a set of phase names defined by ``stack.sh``
-and ```` is the configuration filename. The filename is
-eval'ed in the ``stack.sh`` context so all environment variables are
-available and may be used. Using the project config file variables in
-the header is strongly suggested (see the ``NOVA_CONF`` example below).
-If the path of the config file does not exist it is skipped.
-
-The defined phases are:
-
-* **local** - extracts ``localrc`` from ``local.conf`` before ``stackrc`` is sourced
-* **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
-
-The file is processed strictly in sequence; meta-sections may be specified more
-than once but if any settings are duplicated the last to appear in the file
-will be used.
-
- [[post-config|$NOVA_CONF]]
- [DEFAULT]
- use_syslog = True
-
- [osapi_v3]
- enabled = False
-
-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.
-
- [[local|localrc]]
- FIXED_RANGE=10.254.1.0/24
- ADMIN_PASSWORD=speciale
- LOGFILE=$DEST/logs/stack.sh.log
-
-Note that ``Q_PLUGIN_CONF_FILE`` is unique in that it is assumed to *NOT*
-start with a ``/`` (slash) character. A slash will need to be added:
-
- [[post-config|/$Q_PLUGIN_CONF_FILE]]
diff --git a/README.rst b/README.rst
new file mode 100644
index 0000000000..6885546c94
--- /dev/null
+++ b/README.rst
@@ -0,0 +1,97 @@
+DevStack is a set of scripts and utilities to quickly deploy an OpenStack cloud
+from git source trees.
+
+Goals
+=====
+
+* 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?)
+* To make it easier for developers to dive into OpenStack so that they can
+ productively contribute without having to understand every part of the
+ system at once
+* To make it easy to prototype cross-project features
+* To provide an environment for the OpenStack CI testing on every commit
+ to the projects
+
+Read more at https://docs.openstack.org/devstack/latest
+
+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
+========
+
+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 Pike OpenStack cloud::
+
+ git checkout stable/pike
+ ./stack.sh
+
+You can also pick specific OpenStack project releases by setting the appropriate
+`*_BRANCH` variables in the ``localrc`` section of `local.conf` (look in
+`stackrc` for the default set). Usually just before a release there will be
+milestone-proposed branches that need to be tested::
+
+ GLANCE_REPO=git://git.openstack.org/openstack/glance.git
+ GLANCE_BRANCH=milestone-proposed
+
+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
+your VM. To start a dev cloud run the following NOT AS ROOT (see
+**DevStack Execution Environment** below for more on user accounts):
+
+ ./stack.sh
+
+When the script finishes executing, you should be able to access OpenStack
+endpoints, like so:
+
+* Horizon: http://myhost/
+* Keystone: http://myhost/identity/v2.0/
+
+We also provide an environment file that you can use to interact with your
+cloud via CLI::
+
+ # source openrc file to load your environment with OpenStack CLI creds
+ . openrc
+ # list instances
+ openstack server list
+
+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
+for disappointment, or worse. Alas, we're all in the virtualization business
+here, so run it in a VM. And take advantage of the snapshot capabilities
+of your hypervisor of choice to reduce testing cycle times. You might even save
+enough time to write one more feature before the next feature freeze...
+
+``stack.sh`` needs to have root access for a lot of tasks, but uses
+``sudo`` for all of those tasks. However, it needs to be not-root for
+most of its work and for all of the OpenStack services. ``stack.sh``
+specifically does not run if started as root.
+
+DevStack will not automatically create the user, but provides a helper
+script in ``tools/create-stack-user.sh``. Run that (as root!) or just
+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
+===========
+
+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
+`_
+for details of the configuration file and the many available options.
diff --git a/clean.sh b/clean.sh
index c31a65fd40..a29ebd94f0 100755
--- a/clean.sh
+++ b/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_UPDATE``, ``os_PACKAGE``, ``os_CODENAME``
+# ``os_RELEASE``, ``os_PACKAGE``, ``os_CODENAME``
# and ``DISTRO``
GetDistro
@@ -41,17 +41,18 @@ source $TOP_DIR/lib/rpc_backend
source $TOP_DIR/lib/tls
source $TOP_DIR/lib/oslo
+source $TOP_DIR/lib/lvm
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/ceilometer
-source $TOP_DIR/lib/heat
+source $TOP_DIR/lib/neutron
source $TOP_DIR/lib/neutron-legacy
-source $TOP_DIR/lib/ironic
+set -o xtrace
# Extras Source
# --------------
@@ -63,13 +64,8 @@ if [[ -d $TOP_DIR/extras.d ]]; then
done
fi
-# 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
+# Let unstack.sh do its thing first
+$TOP_DIR/unstack.sh --all
# Run extras
# ==========
@@ -92,8 +88,10 @@ 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
@@ -105,7 +103,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/heat /etc/neutron
+sudo rm -rf /etc/keystone /etc/glance /etc/nova /etc/cinder /etc/swift /etc/neutron /etc/openstack/
# Clean out tgt
sudo rm -f /etc/tgt/conf.d/*
@@ -124,19 +122,37 @@ fi
if [[ -n "$LOGDIR" ]] && [[ -d "$LOGDIR" ]]; then
sudo rm -rf $LOGDIR
fi
-if [[ -n "$SCREEN_LOGDIR" ]] && [[ -d "$SCREEN_LOGDIR" ]]; then
- sudo rm -rf $SCREEN_LOGDIR
+
+# Clean out the sytemd user unit files if systemd was used.
+if [[ "$USE_SYSTEMD" = "True" ]]; then
+ sudo find $SYSTEMD_DIR -type f -name '*devstack@*service' -delete
+ # Make systemd aware of the deletion.
+ $SYSTEMCTL daemon-reload
fi
# Clean up venvs
-DIRS_TO_CLEAN="$WHEELHOUSE ${PROJECT_VENV[@]}"
+DIRS_TO_CLEAN="$WHEELHOUSE ${PROJECT_VENV[@]} .config/openstack"
rm -rf $DIRS_TO_CLEAN
# Clean up files
-FILES_TO_CLEAN=".localrc.auto docs/files docs/html shocco/ stack-screenrc test*.conf* test.ini*"
+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+=".stackenv .prereqs"
for file in $FILES_TO_CLEAN; do
rm -rf $TOP_DIR/$file
done
+
+rm -rf ~/.config/openstack
+
+# Clean up all *.pyc files
+if [[ -n "$DEST" ]] && [[ -d "$DEST" ]]; then
+ find_version=`find --version | awk '{ print $NF; exit}'`
+ if vercmp "$find_version" "<" "4.2.3" ; then
+ sudo find $DEST -name "*.pyc" -print0 | xargs -0 rm
+ else
+ sudo find $DEST -name "*.pyc" -delete
+ fi
+fi
diff --git a/data/devstack-plugins-registry.header b/data/devstack-plugins-registry.header
new file mode 100644
index 0000000000..576dbbd35a
--- /dev/null
+++ b/data/devstack-plugins-registry.header
@@ -0,0 +1,21 @@
+.. 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.
diff --git a/doc/requirements.txt b/doc/requirements.txt
new file mode 100644
index 0000000000..f65e9dfece
--- /dev/null
+++ b/doc/requirements.txt
@@ -0,0 +1,11 @@
+pbr>=2.0.0,!=2.1.0
+
+Pygments
+docutils
+sphinx>=1.6.2
+openstackdocstheme>=1.11.0
+nwdiag
+blockdiag
+sphinxcontrib-blockdiag
+sphinxcontrib-nwdiag
+zuul-sphinx>=0.2.0
diff --git a/doc/source/assets/images/screen_session_1.png b/doc/source/assets/images/screen_session_1.png
new file mode 100644
index 0000000000..6ad6752bb1
Binary files /dev/null and b/doc/source/assets/images/screen_session_1.png differ
diff --git a/doc/source/assets/local.conf b/doc/source/assets/local.conf
new file mode 120000
index 0000000000..cfc2a4e9d8
--- /dev/null
+++ b/doc/source/assets/local.conf
@@ -0,0 +1 @@
+../../../samples/local.conf
\ No newline at end of file
diff --git a/doc/source/changes.rst b/doc/source/changes.rst
deleted file mode 100644
index 19fce0fd52..0000000000
--- a/doc/source/changes.rst
+++ /dev/null
@@ -1,12 +0,0 @@
-=======
-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 `__.
-
-%GIT_LOG%
diff --git a/doc/source/conf.py b/doc/source/conf.py
index 3e9aa45911..e9708fae1d 100644
--- a/doc/source/conf.py
+++ b/doc/source/conf.py
@@ -26,7 +26,13 @@
# Add any Sphinx extension module names here, as strings. They can be extensions
# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
-extensions = [ 'oslosphinx' ]
+extensions = [ 'sphinx.ext.autodoc', 'zuul_sphinx', 'openstackdocstheme', 'sphinxcontrib.blockdiag', 'sphinxcontrib.nwdiag' ]
+
+# openstackdocstheme options
+repository_name = 'openstack-dev/devstack'
+bug_project = 'devstack'
+bug_tag = ''
+html_last_updated_fmt = '%Y-%m-%d %H:%M'
todo_include_todos = True
@@ -87,7 +93,7 @@
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
-html_theme = 'nature'
+html_theme = 'openstackdocs'
# 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
diff --git a/doc/source/configuration.rst b/doc/source/configuration.rst
index 1cc7083bb4..022e6ba529 100644
--- a/doc/source/configuration.rst
+++ b/doc/source/configuration.rst
@@ -2,40 +2,28 @@
Configuration
=============
-DevStack has always tried to be mostly-functional with a minimal amount
-of configuration. The number of options has ballooned as projects add
-features, new projects added and more combinations need to be tested.
-Historically DevStack obtained all local configuration and
-customizations from a ``localrc`` file. The number of configuration
-variables that are simply passed-through to the individual project
-configuration files is also increasing. The old mechanism for this
-(``EXTRAS_OPTS`` and friends) required specific code for each file and
-did not scale well.
-
-In Oct 2013 a new configuration method was introduced (in `review
-46768 `__) to hopefully
-simplify this process and meet the following goals:
-
-- contain all non-default local configuration in a single file
-- be backward-compatible with ``localrc`` to smooth the transition
- process
-- allow settings in arbitrary configuration files to be changed
+.. contents::
+ :local:
+ :depth: 1
local.conf
==========
-The new configuration file is ``local.conf`` and resides in the root
-DevStack directory like the old ``localrc`` file. It is a modified INI
-format file that introduces a meta-section header to carry additional
-information regarding the configuration files to be changed.
+DevStack configuration is modified via the file ``local.conf``. It is
+a modified INI format file that introduces a meta-section header to
+carry additional information regarding the configuration files to be
+changed.
+
+A sample is provided in ``devstack/samples``
The new header is similar to a normal INI section header but with double
brackets (``[[ ... ]]``) and two internal fields separated by a pipe
-(``|``):
-
+(``|``). Note that there are no spaces between the double brackets and the
+internal fields. Likewise, there are no spaces between the pipe and the
+internal fields:
::
- [[ | ]]
+ '[[' '|' ']]'
where ```` is one of a set of phase names defined by ``stack.sh``
and ```` is the configuration filename. The filename
@@ -48,14 +36,12 @@ 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
@@ -73,13 +59,12 @@ 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. More
-details on the :doc:`contents of local.conf ` are available.
+exists it will be used instead to preserve backward-compatibility.
::
[[local|localrc]]
- FIXED_RANGE=10.254.1.0/24
+ IPV4_ADDRS_SAFE_TO_USE=10.254.1.0/24
ADMIN_PASSWORD=speciale
LOGFILE=$DEST/logs/stack.sh.log
@@ -95,6 +80,76 @@ 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
@@ -107,20 +162,19 @@ 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 (``FIXED_RANGE`` and
- ``FLOATING_RANGE``, commented out below)
+- move network ranges away from the local network (``IPV4_ADDRS_SAFE_TO_USE``
+ and ``FLOATING_RANGE``, commented out below)
- set the host IP if detection is unreliable (``HOST_IP``, commented
out below)
::
[[local|localrc]]
- ADMIN_PASSWORD=secrete
+ ADMIN_PASSWORD=secret
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
- SERVICE_TOKEN=a682f596-76f3-11e3-b3b2-e716f9080d50
- #FIXED_RANGE=172.31.1.0/24
+ #IPV4_ADDRS_SAFE_TO_USE=172.31.1.0/24
#FLOATING_RANGE=192.168.20.0/25
#HOST_IP=10.3.4.5
@@ -137,137 +191,279 @@ Ethernet interface to a bridge on the host. Setting it here also makes it
available for ``openrc`` to set ``OS_AUTH_URL``. ``HOST_IP`` is not set
by default.
-Common Configuration Variables
-==============================
+``HOST_IPV6`` is normally detected on the first run of ``stack.sh`` but
+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.
-Installation Directory
-----------------------
+For architecture specific configurations which differ from the x86 default
+here, see `arch-configuration`_.
- | *Default: ``DEST=/opt/stack``*
- | The DevStack install directory is set by the ``DEST`` variable.
- | By setting it early in the ``localrc`` section you can reference it
- in later variables. It can be useful to set it even though it is not
- changed from the default value.
- |
+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
+`__) to simplify this
+process.
+
+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.
::
- DEST=/opt/stack
+ NOVA_REPO=$GIT_BASE/openstack/nova.git
+ NOVA_BRANCH=master
-Libraries from Git
-------------------
+To pull a branch directly from Gerrit, get the repo and branch from
+the Gerrit review page:
- | *Default: ``LIBS_FROM_GIT=""``*
+ ::
- | By default devstack installs OpenStack server components from
- git, however it installs client libraries from released versions
- on pypi. This is appropriate if you are working on server
- development, but if you want to see how an unreleased version of
- the client affects the system you can have devstack install it
- from upstream, or from local git trees.
- | Multiple libraries can be specified as a comma separated list.
- |
+ 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:
- LIBS_FROM_GIT=python-keystoneclient,oslo.config
+ ::
-Virtual Environments
---------------------
+ NOVA_REPO=https://review.openstack.org/p/openstack/nova
+ NOVA_BRANCH=refs/changes/50/5050/1
- | *Default: ``USE_VENV=False``*
- | Enable the use of Python virtual environments by setting ``USE_VENV``
- to ``True``. This will enable the creation of venvs for each project
- that is defined in the ``PROJECT_VENV`` array.
- | *Default: ``PROJECT_VENV['']='.venv'*
- | Each entry in the ``PROJECT_VENV`` array contains the directory name
- of a venv to be used for the project. The array index is the project
- name. Multiple projects can use the same venv if desired.
+Installation Directory
+----------------------
- ::
+The DevStack install directory is set by the ``DEST`` variable. By
+default it is ``/opt/stack``.
- PROJECT_VENV["glance"]=${GLANCE_DIR}.venv
+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.
- | *Default: ``ADDITIONAL_VENV_PACKAGES=""``*
- | A comma-separated list of additional packages to be installed into each
- venv. Often projects will not have certain packages listed in its
- ``requirements.txt`` file because they are 'optional' requirements,
- i.e. only needed for certain configurations. By default, the enabled
- databases will have their Python bindings added when they are enabled.
+ ::
+
+ DEST=/opt/stack
+
+Logging
+-------
Enable Logging
---------------
+~~~~~~~~~~~~~~
- | *Defaults: ``LOGFILE="" LOGDAYS=7 LOG_COLOR=True``*
- | By default ``stack.sh`` output is only written to the console
- where is runs. It can be sent to a file in addition to the console
- by setting ``LOGFILE`` to the fully-qualified name of the
- destination log file. A timestamp will be appended to the given
- filename for each run of ``stack.sh``.
- |
+By default ``stack.sh`` output is only written to the console where it
+runs. It can be sent to a file in addition to the console by setting
+``LOGFILE`` to the fully-qualified name of the destination log file. A
+timestamp will be appended to the given filename for each run of
+``stack.sh``.
::
LOGFILE=$DEST/logs/stack.sh.log
- Old log files are cleaned automatically if ``LOGDAYS`` is set to the
- number of days of old log files to keep.
+Old log files are cleaned automatically if ``LOGDAYS`` is set to the
+number of days of old log files to keep.
::
LOGDAYS=1
- The some of the project logs (Nova, Cinder, etc) will be colorized
- by default (if ``SYSLOG`` is not set below); this can be turned off
- by setting ``LOG_COLOR`` False.
-
- ::
+Some coloring is used during the DevStack runs to make it easier to
+see what is going on. This can be disabled with::
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.
+
Logging the Service Output
---------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~
- | *Default: ``LOGDIR=""``*
- | DevStack will log the stdout output of the services it starts.
- When using ``screen`` this logs the output in the screen windows
- to a file. Without ``screen`` this simply redirects stdout of
- the service process to a file in ``LOGDIR``.
- |
+By default, services run under ``systemd`` and are natively logging to
+the systemd journal.
- ::
+To query the logs use the ``journalctl`` command, such as::
+
+ sudo journalctl --unit devstack@*
+
+More examples can be found in :ref:`journalctl-examples`.
+
+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
+
+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:
+
+ ::
+
+ disable_service mysql
+ enable_service postgresql
+
+``mysql`` is the default database.
+
+RPC Backend
+-----------
+
+Support for a RabbitMQ RPC backend is included. Additional RPC
+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``:
+
+::
- LOGDIR=$DEST/logs
+ disable_service rabbit
- *Note the use of ``DEST`` to locate the main install directory; this
- is why we suggest setting it in ``local.conf``.*
-Enabling Syslog
+Apache Frontend
---------------
- | *Default: ``SYSLOG=False SYSLOG_HOST=$HOST_IP SYSLOG_PORT=516``*
- | Logging all services to a single syslog can be convenient. Enable
- syslogging by setting ``SYSLOG`` to ``True``. If the destination log
- host is not localhost ``SYSLOG_HOST`` and ``SYSLOG_PORT`` can be
- used to direct the message stream to the log host.
- |
+The Apache web server can be enabled for wsgi services that support
+being deployed under HTTPD + mod_wsgi. By default, services that
+recommend running under HTTPD + mod_wsgi are deployed under Apache. To
+use an alternative deployment strategy (e.g. eventlet) for services
+that support an alternative to HTTPD + mod_wsgi set
+``ENABLE_HTTPD_MOD_WSGI_SERVICES`` to ``False`` in your
+``local.conf``.
- ::
+Each service that can be run under HTTPD + mod_wsgi also has an
+override toggle available that can be set in your ``local.conf``.
+
+Keystone is run under Apache with ``mod_wsgi`` by default.
+
+Example (Keystone)
+
+::
+
+ KEYSTONE_USE_MOD_WSGI="True"
+
+Example (Nova):
+
+::
+
+ NOVA_USE_MOD_WSGI="True"
+
+Example (Swift):
+
+::
- SYSLOG=True
- SYSLOG_HOST=$HOST_IP
- SYSLOG_PORT=516
+ SWIFT_USE_MOD_WSGI="True"
+
+Example (Heat):
+
+::
+
+ HEAT_USE_MOD_WSGI="True"
+
+
+Example (Cinder):
+
+::
+
+ CINDER_USE_MOD_WSGI="True"
+
+
+Libraries from Git
+------------------
+
+By default devstack installs OpenStack server components from git,
+however it installs client libraries from released versions on pypi.
+This is appropriate if you are working on server development, but if
+you want to see how an unreleased version of the client affects the
+system you can have devstack install it from upstream, or from local
+git trees 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.
+
+Virtual Environments
+--------------------
+
+Enable the use of Python virtual environments by setting ``USE_VENV``
+to ``True``. This will enable the creation of venvs for each project
+that is defined in the ``PROJECT_VENV`` array.
+
+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
+
+``ADDITIONAL_VENV_PACKAGES`` is a comma-separated list of additional
+packages to be installed into each venv. Often projects will not have
+certain packages listed in its ``requirements.txt`` file because they
+are 'optional' requirements, i.e. only needed for certain
+configurations. By default, the enabled databases will have their
+Python bindings added when they are enabled.
+
+ ::
+
+ ADDITIONAL_VENV_PACKAGES="python-foo, python-bar"
+
+Use python3
+------------
+
+By default ``stack.sh`` uses python2 (the exact version set by the
+``PYTHON2_VERSION``). This can be overriden so devstack will run
+python3 (the exact version set by ``PYTHON3_VERSION``).
+
+ ::
+
+ USE_PYTHON3=True
A clean install every time
--------------------------
- | *Default: ``RECLONE=""``*
- | By default ``stack.sh`` only clones the project repos if they do
- not exist in ``$DEST``. ``stack.sh`` will freshen each repo on each
- run if ``RECLONE`` is set to ``yes``. This avoids having to manually
- remove repos in order to get the current branch from ``$GIT_BASE``.
- |
+By default ``stack.sh`` only clones the project repos if they do not
+exist in ``$DEST``. ``stack.sh`` will freshen each repo on each run if
+``RECLONE`` is set to ``yes``. This avoids having to manually remove
+repos in order to get the current branch from ``$GIT_BASE``.
::
@@ -276,172 +472,333 @@ A clean install every time
Upgrade packages installed by pip
---------------------------------
- | *Default: ``PIP_UPGRADE=""``*
- | By default ``stack.sh`` only installs Python packages if no version
- is currently installed or the current version does not match a specified
- requirement. If ``PIP_UPGRADE`` is set to ``True`` then existing required
- Python packages will be upgraded to the most recent version that
- matches requirements.
- |
+By default ``stack.sh`` only installs Python packages if no version is
+currently installed or the current version does not match a specified
+requirement. If ``PIP_UPGRADE`` is set to ``True`` then existing
+required Python packages will be upgraded to the most recent version
+that matches requirements.
::
PIP_UPGRADE=True
-Swift
------
+Guest Images
+------------
+
+Images provided in URLS via the comma-separated ``IMAGE_URLS``
+variable will be downloaded and uploaded to glance by DevStack.
+
+Default guest-images are predefined for each type of hypervisor and
+their testing-requirements in ``stack.sh``. Setting
+``DOWNLOAD_DEFAULT_IMAGES=False`` will prevent DevStack downloading
+these default images; in that case, you will want to populate
+``IMAGE_URLS`` with sufficient images to satisfy testing-requirements.
- | Default: SWIFT_HASH=""
- | SWIFT_REPLICAS=1
- | SWIFT_DATA_DIR=$DEST/data/swift
+ ::
+
+ DOWNLOAD_DEFAULT_IMAGES=False
+ IMAGE_URLS="http://foo.bar.com/image.qcow,"
+ IMAGE_URLS+="http://foo.bar.com/image2.qcow"
+
+
+Instance Type
+-------------
- | Swift is now used as the back-end for the S3-like object store.
- When enabled Nova's objectstore (n-obj in ENABLED_SERVICES) is
- automatically disabled. Enable Swift by adding it services to
- ENABLED_SERVICES: enable_service s-proxy s-object s-container
- s-account
+``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.
- Setting Swift's hash value is required and you will be prompted for
- it if Swift is enabled so just set it to something already:
+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 `__ so users
+running instances on ppc64/ppc64le can choose one of the default
+created flavors as follows:
::
- SWIFT_HASH=66a3d6b56c1f479c8b4e70ab5c2000f5
+ DEFAULT_INSTANCE_TYPE=m1.tiny
+
+
+IP Version
+----------
- For development purposes the default number of replicas is set to
- ``1`` to reduce the overhead required. To better simulate a
- production deployment set this to ``3`` or more.
+``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.
::
- SWIFT_REPLICAS=3
+ IP_VERSION=4+6
- The data for Swift is stored in the source tree by default (in
- ``$DEST/swift/data``) and can be moved by setting
- ``SWIFT_DATA_DIR``. The specified directory will be created if it
- does not exist.
+The following optional variables can be used to alter the default IPv6
+behavior:
::
- SWIFT_DATA_DIR=$DEST/data/swift
+ 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
+
+*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.
+
+Service Version
+~~~~~~~~~~~~~~~
+
+DevStack can enable service operation over either IPv4 or IPv6 by
+setting ``SERVICE_IP_VERSION`` to either ``SERVICE_IP_VERSION=4`` or
+``SERVICE_IP_VERSION=6`` respectively.
- *Note: Previously just enabling ``swift`` was sufficient to start
- the Swift services. That does not provide proper service
- granularity, particularly in multi-host configurations, and is
- considered deprecated. Some service combination tests now check for
- specific Swift services and the old blanket acceptance will longer
- work correctly.*
+When set to ``4`` devstack services will open listen sockets on
+``0.0.0.0`` and service endpoints will be registered using ``HOST_IP``
+as the address.
-Service Catalog Backend
------------------------
+When set to ``6`` devstack services will open listen sockets on ``::``
+and service endpoints will be registered using ``HOST_IPV6`` as the
+address.
- | *Default: ``KEYSTONE_CATALOG_BACKEND=sql``*
- | DevStack uses Keystone's ``sql`` service catalog backend. An
- alternate ``template`` backend is also available. However, it does
- not support the ``service-*`` and ``endpoint-*`` commands of the
- ``keystone`` CLI. To do so requires the ``sql`` backend be enabled:
- |
+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
::
- KEYSTONE_CATALOG_BACKEND=template
+ HOST_IPV6=${some_local_ipv6_address}
+
+Multi-node setup
+~~~~~~~~~~~~~~~~
+
+See the :doc:`multi-node lab guide`
+
+Projects
+--------
+
+Neutron
+~~~~~~~
+
+See the :doc:`neutron configuration guide` for
+details on configuration of Neutron
+
+
+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.
+
+If you would like to enable Swift you can add this to your ``localrc``
+section:
+
+::
+
+ enable_service s-proxy s-object s-container s-account
- DevStack's default configuration in ``sql`` mode is set in
- ``files/keystone_data.sh``
+If you want a minimal Swift install with only Swift and Keystone you
+can have this instead in your ``localrc`` section:
+
+::
+
+ disable_all_services
+ enable_service key mysql s-proxy s-object s-container s-account
+
+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 S3
+++++++++
+
+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``.
+
+Only Swift proxy server is launched in the systemd system all other
+services are started in background and managed by ``swift-init`` tool.
+
+Tempest
+~~~~~~~
+
+If tempest has been successfully configured, a basic set of smoke
+tests can be run as follows:
+
+::
+
+ $ cd /opt/stack/tempest
+ $ 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
+package install includes installing dependences). So tempest won't run
+outside of tox. If you would like to install it add the following to your
+``localrc`` section:
+
+::
+
+ 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 `__ 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.
Cinder
-------
+~~~~~~
- | Default:
- | VOLUME_GROUP="stack-volumes" VOLUME_NAME_PREFIX="volume-" VOLUME_BACKING_FILE_SIZE=10250M
- | The logical volume group used to hold the Cinder-managed volumes
- is set by ``VOLUME_GROUP``, the logical volume name prefix is set
- with ``VOLUME_NAME_PREFIX`` and the size of the volume backing file
- is set with ``VOLUME_BACKING_FILE_SIZE``.
- |
+The logical volume group used to hold the Cinder-managed volumes is
+set by ``VOLUME_GROUP_NAME``, 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="stack-volumes"
+ VOLUME_GROUP_NAME="stack-volumes"
VOLUME_NAME_PREFIX="volume-"
- VOLUME_BACKING_FILE_SIZE=10250M
+ VOLUME_BACKING_FILE_SIZE=24G
-Multi-host DevStack
--------------------
- | *Default: ``MULTI_HOST=False``*
- | Running DevStack with multiple hosts requires a custom
- ``local.conf`` section for each host. The master is the same as a
- single host installation with ``MULTI_HOST=True``. The slaves have
- fewer services enabled and a couple of host variables pointing to
- the master.
- | **Master**
+Keystone
+~~~~~~~~
- ::
+Multi-Region Setup
+++++++++++++++++++
- MULTI_HOST=True
+We want to setup two devstack (RegionOne and RegionTwo) with shared
+keystone (same users and services) and horizon. Keystone and Horizon
+will be located in RegionOne. Full spec is available at:
+``__.
- **Slave**
+In RegionOne:
- ::
+::
- MYSQL_HOST=w.x.y.z
- RABBIT_HOST=w.x.y.z
- GLANCE_HOSTPORT=w.x.y.z:9292
- ENABLED_SERVICES=n-vol,n-cpu,n-net,n-api
+ REGION_NAME=RegionOne
-IP Version
- | Default: ``IP_VERSION=4``
- | This setting can be used to configure DevStack to create either an IPv4,
- IPv6, or dual stack tenant data network by setting ``IP_VERSION`` to
- either ``IP_VERSION=4``, ``IP_VERSION=6``, or ``IP_VERSION=4+6``
- respectively. This functionality requires that the Neutron networking
- service is enabled by setting the following options:
- |
+In RegionTwo:
- ::
+::
- disable_service n-net
- enable_service q-svc q-agt q-dhcp q-l3
+ disable_service horizon
+ KEYSTONE_SERVICE_HOST=
+ KEYSTONE_AUTH_HOST=
+ REGION_NAME=RegionTwo
+ KEYSTONE_REGION_NAME=RegionOne
- | The following optional variables can be used to alter the default IPv6
- behavior:
- |
+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.
- ::
+Disabling Identity API v2
++++++++++++++++++++++++++
- 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
+The Identity API v2 is deprecated as of Mitaka and it is recommended to only
+use the v3 API. It is possible to setup keystone without v2 API, by doing:
- | *Note: ``FIXED_RANGE_V6`` and ``IPV6_PRIVATE_NETWORK_GATEWAY``
- can be configured with any valid IPv6 prefix. The default values make
- use of an auto-generated ``IPV6_GLOBAL_ID`` to comply with RFC 4193.*
+::
-Examples
-========
+ ENABLE_IDENTITY_V2=False
-- Eliminate a Cinder pass-through (``CINDER_PERIODIC_INTERVAL``):
+.. _arch-configuration:
- ::
+Architectures
+-------------
- [[post-config|$CINDER_CONF]]
- [DEFAULT]
- periodic_interval = 60
+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.
-- Sample ``local.conf`` with screen logging enabled:
+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]]
- FIXED_RANGE=10.254.1.0/24
- NETWORK_GATEWAY=10.254.1.1
- LOGDAYS=1
- LOGDIR=$DEST/logs
- LOGFILE=$LOGDIR/stack.sh.log
- ADMIN_PASSWORD=quiet
- DATABASE_PASSWORD=$ADMIN_PASSWORD
- RABBIT_PASSWORD=$ADMIN_PASSWORD
- SERVICE_PASSWORD=$ADMIN_PASSWORD
- SERVICE_TOKEN=a682f596-76f3-11e3-b3b2-e716f9080d50
+ [[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--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=
+ ETCD_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!
diff --git a/doc/source/development.rst b/doc/source/development.rst
new file mode 100644
index 0000000000..957de9b0e1
--- /dev/null
+++ b/doc/source/development.rst
@@ -0,0 +1,117 @@
+==========================
+ 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.
diff --git a/doc/source/eucarc.rst b/doc/source/eucarc.rst
deleted file mode 100644
index c2ecbc6732..0000000000
--- a/doc/source/eucarc.rst
+++ /dev/null
@@ -1,45 +0,0 @@
-=====================
-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}
diff --git a/doc/source/exerciserc.rst b/doc/source/exerciserc.rst
deleted file mode 100644
index dacae2ecf2..0000000000
--- a/doc/source/exerciserc.rst
+++ /dev/null
@@ -1,42 +0,0 @@
-==============================
-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
diff --git a/doc/source/faq.rst b/doc/source/faq.rst
index d3b491fdac..efb315cbee 100644
--- a/doc/source/faq.rst
+++ b/doc/source/faq.rst
@@ -2,176 +2,233 @@
FAQ
===
-- `General Questions <#general>`__
-- `Operation and Configuration <#ops_conf>`__
-- `Miscellaneous <#misc>`__
+.. contents::
+ :local:
General Questions
=================
-Q: Can I use DevStack for production?
- A: No. We mean it. Really. DevStack makes some implementation
- choices that are not appropriate for production deployments. We
- warned you!
-Q: Then why selinux in enforcing mode?
- A: That is the default on current Fedora and RHEL releases. DevStack
- has (rightly so) a bad reputation for its security practices; it has
- always been meant as a development tool first and system integration
- later. This is changing as the security issues around OpenStack's
- use of root (for example) have been tightened and developers need to
- be better equipped to work in these environments. ``stack.sh``'s use
- of root is primarily to support the activities that would be handled
- by packaging in "real" deployments. To remove additional protections
- that will be desired/required in production would be a step
- backward.
-Q: But selinux is disabled in RHEL!
- A: Today it is, yes. That is a specific exception that certain
- DevStack contributors fought strongly against. The primary reason it
- was allowed was to support using RHEL6 as the Python 2.6 test
- platform and that took priority time-wise. This will not be the case
- with RHEL 7.
-Q: Why a shell script, why not chef/puppet/...
- A: The script is meant to be read by humans (as well as ran by
- computers); it is the primary documentation after all. Using a
- recipe system requires everyone to agree and understand chef or
- puppet.
-Q: Why not use Crowbar?
- A: DevStack is optimized for documentation & developers. As some of
- us use `Crowbar `__ for
- production deployments, we hope developers documenting how they
- setup systems for new features supports projects like Crowbar.
-Q: I'd like to help!
- A: That isn't a question, but please do! The source for DevStack is
- at
- `git.openstack.org `__
- and bug reports go to
- `LaunchPad `__. Contributions
- follow the usual process as described in the `developer
- guide `__. This Sphinx
- documentation is housed in the doc directory.
-Q: Why not use packages?
- A: Unlike packages, DevStack leaves your cloud ready to develop -
- checkouts of the code and services running in screen. However, many
- people are doing the hard work of packaging and recipes for
- production deployments. We hope this script serves as a way to
- communicate configuration changes between developers and packagers.
-Q: Why isn't $MY\_FAVORITE\_DISTRO supported?
- A: DevStack is meant for developers and those who want to see how
- OpenStack really works. DevStack is known to run on the
- distro/release combinations listed in ``README.md``. DevStack is
- only supported on releases other than those documented in
- ``README.md`` on a best-effort basis.
-Q: What about Fedora/RHEL/CentOS?
- A: Fedora and CentOS/RHEL are supported via rpm dependency files and
- specific checks in ``stack.sh``. Support will follow the pattern set
- with the Ubuntu testing, i.e. only a single release of the distro
- will receive regular testing, others will be handled on a
- best-effort basis.
-Q: Are there any differences between Ubuntu and Fedora support?
- A: Neutron is not fully supported prior to Fedora 18 due lack of
- OpenVSwitch packages.
-Q: Why can't I use another shell?
- A: DevStack now uses some specific bash-ism that require Bash 4, such
- as associative arrays. Simple compatibility patches have been accepted
- in the past when they are not complex, at this point no additional
- compatibility patches will be considered except for shells matching
- the array functionality as it is very ingrained in the repo and project
- management.
-Q: But, but, can't I test on OS/X?
- A: Yes, even you, core developer who complained about this, needs to
- install bash 4 via homebrew to keep running tests on OS/X. Get a Real
- Operating System. (For most of you who don't know, I am referring to
- myself.)
+Can I use DevStack for production?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+DevStack is targeted at developers and CI systems to use the raw
+upstream code. It makes many choices that are not appropriate for
+production systems.
+
+Your best choice is probably to choose a `distribution of OpenStack
+`__.
+
+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/``) 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/...
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The script is meant to be read by humans (as well as ran by
+computers); it is the primary documentation after all. Using a recipe
+system requires everyone to agree and understand chef or puppet.
+
+I'd like to help!
+~~~~~~~~~~~~~~~~~
+
+That isn't a question, but please do! The source for DevStack is at
+`git.openstack.org
+`__ and bug
+reports go to `LaunchPad
+`__. Contributions follow the
+usual process as described in the `developer guide
+`__. 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
+deployments.
+
+Why isn't $MY\_FAVORITE\_DISTRO supported?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+DevStack is meant for developers and those who want to see how
+OpenStack really works. DevStack is known to run on the distro/release
+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?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Both should work well and are tested by DevStack CI.
+
+Why can't I use another shell?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+DevStack now uses some specific bash-ism that require Bash 4, such as
+associative arrays. Simple compatibility patches have been accepted in
+the past when they are not complex, at this point no additional
+compatibility patches will be considered except for shells matching
+the array functionality as it is very ingrained in the repo and
+project management.
+
+Can I test on OS/X?
+~~~~~~~~~~~~~~~~~~~
+
+Some people have success with bash 4 installed via homebrew to keep
+running tests on OS/X.
+
+Can I at least source ``openrc`` with ``zsh``?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+People have reported success with a special function to run ``openrc``
+through bash for this
+
+.. code-block:: bash
+
+ function sourceopenrc {
+ pushd ~/devstack >/dev/null
+ eval $(bash -c ". openrc $1 $2 >/dev/null;env|sed -n '/OS_/ { s/^/export /;p}'")
+ popd >/dev/null
+ }
+
Operation and Configuration
===========================
-Q: Can DevStack handle a multi-node installation?
- A: Indirectly, yes. You run DevStack on each node with the
- appropriate configuration in ``local.conf``. The primary
- considerations are turning off the services not required on the
- secondary nodes, making sure the passwords match and setting the
- various API URLs to the right place.
-Q: How can I document the environment that DevStack is using?
- A: DevStack includes a script (``tools/info.sh``) that gathers the
- versions of the relevant installed apt packages, pip packages and
- git repos. This is a good way to verify what Python modules are
- installed.
-Q: How do I turn off a service that is enabled by default?
- A: Services can be turned off by adding ``disable_service xxx`` to
- ``local.conf`` (using ``n-vol`` in this example):
+Can DevStack handle a multi-node installation?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- ::
+Yes, see :doc:`multinode lab guide `
+
+How can I document the environment that DevStack is using?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+DevStack includes a script (``tools/info.sh``) that gathers the
+versions of the relevant installed apt packages, pip packages and git
+repos. This is a good way to verify what Python modules are
+installed.
- disable_service n-vol
+How do I turn off a service that is enabled by default?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Q: Is enabling a service that defaults to off done with the reverse of the above?
- A: Of course!
+Services can be turned off by adding ``disable_service xxx`` to
+``local.conf`` (using ``c-vol`` in this example):
::
- enable_service qpid
+ disable_service c-vol
-Q: How do I run a specific OpenStack milestone?
- A: 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:
+Is enabling a service that defaults to off done with the reverse of the above?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Of course!
::
- [[local|localrc]]
- GLANCE_BRANCH=stable/juno
- HORIZON_BRANCH=stable/juno
- KEYSTONE_BRANCH=stable/juno
- NOVA_BRANCH=stable/juno
- GLANCE_BRANCH=stable/juno
- NEUTRON_BRANCH=stable/juno
- SWIFT_BRANCH=2.2.1
-
-Q: Why not use [STRIKEOUT:``tools/pip-requires``]\ ``requirements.txt`` to grab project dependencies?
- [STRIKEOUT:The majority of deployments will use packages to install
- OpenStack that will have distro-based packages as dependencies.
- DevStack installs as many of these Python packages as possible to
- mimic the expected production environment.] Certain Linux
- distributions have a 'lack of workaround' in their Python
- configurations that installs vendor packaged Python modules and
- pip-installed modules to the SAME DIRECTORY TREE. This is causing
- heartache and moving us in the direction of installing more modules
- from PyPI than vendor packages. However, that is only being done as
- necessary as the packaging needs to catch up to the development
- cycle anyway so this is kept to a minimum.
-Q: What can I do about RabbitMQ not wanting to start on my fresh new VM?
- A: This is often caused by ``erlang`` not being happy with the
- hostname resolving to a reachable IP address. Make sure your
- hostname resolves 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.
-Q: How can I set up Heat in stand-alone configuration?
- A: Configure ``local.conf`` thusly:
+ enable_service q-svc
- ::
+How do I run a specific OpenStack release?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+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.
+
+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]]
- HEAT_STANDALONE=True
- ENABLED_SERVICES=rabbit,mysql,heat,h-api,h-api-cfn,h-api-cw,h-eng
- KEYSTONE_SERVICE_HOST=
- KEYSTONE_AUTH_HOST=
-
-Q: Why are my configuration changes ignored?
- A: You may have run into the package prerequisite installation
- timeout. ``tools/install_prereqs.sh`` has a timer that skips the
- package installation checks if it was run within the last
- ``PREREQ_RERUN_HOURS`` hours (default is 2). To override this, set
- ``FORCE_PREREQ=1`` and the package checks will never be skipped.
+ 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.
+
+What can I do about RabbitMQ not wanting to start on my fresh new VM?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This is often caused by ``erlang`` not being happy with the hostname
+resolving to a reachable IP address. Make sure your hostname resolves
+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.
+
+Why are my configuration changes ignored?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You may have run into the package prerequisite installation
+timeout. ``tools/install_prereqs.sh`` has a timer that skips the
+package installation checks if it was run within the last
+``PREREQ_RERUN_HOURS`` hours (default is 2). To override this, set
+``FORCE_PREREQ=1`` and the package checks will never be skipped.
Miscellaneous
=============
-Q: ``tools/fixup_stuff.sh`` is broken and shouldn't 'fix' just one version of packages.
- A: [Another not-a-question] No it isn't. Stuff in there is to
- correct problems in an environment that need to be fixed elsewhere
- or may/will be fixed in a future release. In the case of
- ``httplib2`` and ``prettytable`` specific problems with specific
- versions are being worked around. If later releases have those
- problems than we'll add them to the script. Knowing about the broken
- future releases is valuable rather than polling to see if it has
- been fixed.
+``tools/fixup_stuff.sh`` is broken and shouldn't 'fix' just one version of packages.
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Stuff in there is to correct problems in an environment that need to
+be fixed elsewhere or may/will be fixed in a future release. In the
+case of ``httplib2`` and ``prettytable`` specific problems with
+specific versions are being worked around. If later releases have
+those problems than we'll add them to the script. Knowing about the
+broken future releases is valuable rather than polling to see if it
+has been fixed.
diff --git a/doc/source/guides.rst b/doc/source/guides.rst
new file mode 100644
index 0000000000..82e0dd6ac6
--- /dev/null
+++ b/doc/source/guides.rst
@@ -0,0 +1,74 @@
+Guides
+======
+
+.. warning::
+
+ The guides are point in time contributions, and may not always be
+ up to date with the latest work in devstack.
+
+Walk through various setups used by stackers
+
+.. toctree::
+ :glob:
+ :maxdepth: 1
+
+ guides/single-vm
+ guides/single-machine
+ guides/lxc
+ guides/multinode-lab
+ guides/neutron
+ guides/devstack-with-nested-kvm
+ guides/nova
+ guides/devstack-with-lbaas-v2
+ guides/devstack-with-ldap
+
+All-In-One Single VM
+--------------------
+
+Run :doc:`OpenStack in a 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] `
+
+All-In-One Single Machine
+-------------------------
+
+Run :doc:`OpenStack on dedicated hardware ` This can include a
+server-class machine or a laptop at home.
+:doc:`[Read] `
+
+All-In-One LXC Container
+-------------------------
+
+Run :doc:`OpenStack in a LXC container `. 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] `
+
+Multi-Node Lab
+--------------
+
+Setup a :doc:`multi-node cluster ` with dedicated VLANs for VMs & Management.
+:doc:`[Read] `
+
+DevStack with Neutron Networking
+--------------------------------
+
+Building a DevStack cluster with :doc:`Neutron Networking `.
+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
+`. 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 `.
+
+Deploying DevStack with LDAP
+----------------------------
+
+Guide to setting up :doc:`DevStack with LDAP `.
diff --git a/doc/source/guides/devstack-with-lbaas-v2.rst b/doc/source/guides/devstack-with-lbaas-v2.rst
index f67978310d..df3c7ce2ac 100644
--- a/doc/source/guides/devstack-with-lbaas-v2.rst
+++ b/doc/source/guides/devstack-with-lbaas-v2.rst
@@ -1,54 +1,57 @@
-Configure Load-Balancer in Kilo
+Configure Load-Balancer Version 2
=================================
-The Kilo release of OpenStack will support Version 2 of the neutron load balancer. Until now, using OpenStack `LBaaS V2 `_ has required a good understanding of neutron and LBaaS architecture and several manual steps.
+Starting in the OpenStack Liberty release, the
+`neutron LBaaS v2 API `_
+is now stable while the LBaaS v1 API has been deprecated. The LBaaS v2 reference
+driver is based on Octavia.
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.
+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
+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
+ enable_plugin octavia https://git.openstack.org/openstack/octavia
# ===== 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"
+ ENABLED_SERVICES+=,n-api,n-cpu,n-cond,n-sch
# Glance
ENABLED_SERVICES+=,g-api,g-reg
# Neutron
ENABLED_SERVICES+=,q-svc,q-agt,q-dhcp,q-l3,q-meta
- # Enable LBaaS V2
+ # Enable LBaaS v2
ENABLED_SERVICES+=,q-lbaasv2
+ ENABLED_SERVICES+=,octavia,o-cw,o-hk,o-hm,o-api
# Cinder
ENABLED_SERVICES+=,c-api,c-vol,c-sch
# Tempest
@@ -57,30 +60,30 @@ Edit your `local.conf` to look like
Run stack.sh and do some sanity checks
- ::
+::
./stack.sh
. ./openrc
- neutron net-list # should show public and private networks
+ 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
- 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 boot --image $(nova image-list | awk '/ cirros-.*-x86_64-uec / {print $2}') --flavor 1 --nic net-id=$(openstack network list | awk '/ private / {print $2}') node1
+ nova boot --image $(nova image-list | awk '/ cirros-.*-x86_64-uec / {print $2}') --flavor 1 --nic net-id=$(openstack network 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
+ #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. 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&
@@ -88,12 +91,19 @@ Set up a simple web server on each of these instances. ssh into each instance (u
Phase 2: Create your load balancers
------------------------------------
- ::
+::
neutron lbaas-loadbalancer-create --name lb1 private-subnet
+ neutron lbaas-loadbalancer-show lb1 # Wait for the provisioning_status to be ACTIVE.
neutron lbaas-listener-create --loadbalancer lb1 --protocol HTTP --protocol-port 80 --name listener1
+ sleep 10 # Sleep since LBaaS actions can take a few seconds depending on the environment.
neutron lbaas-pool-create --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP --name pool1
+ sleep 10
neutron lbaas-member-create --subnet private-subnet --address 10.0.0.3 --protocol-port 80 pool1
+ sleep 10
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.
+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.
diff --git a/doc/source/guides/devstack-with-ldap.rst b/doc/source/guides/devstack-with-ldap.rst
new file mode 100644
index 0000000000..ec411419b5
--- /dev/null
+++ b/doc/source/guides/devstack-with-ldap.rst
@@ -0,0 +1,174 @@
+============================
+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
+will 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``::
+
+ 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::
+
+ ./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.
diff --git a/doc/source/guides/devstack-with-nested-kvm.rst b/doc/source/guides/devstack-with-nested-kvm.rst
index b35492ea17..3732f06fd8 100644
--- a/doc/source/guides/devstack-with-nested-kvm.rst
+++ b/doc/source/guides/devstack-with-nested-kvm.rst
@@ -50,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
@@ -73,7 +73,7 @@ back:
::
sudo rmmod kvm-amd
- sudo sh -c "echo 'options amd nested=1' >> /etc/modprobe.d/dist.conf"
+ sudo sh -c "echo 'options kvm-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
@@ -88,7 +88,7 @@ host:
parm: nested:int
To make the above value persistent across reboots, add an entry in
-/etc/modprobe.ddist.conf so it looks as below::
+/etc/modprobe.d/dist.conf so it looks as below::
cat /etc/modprobe.d/dist.conf
options kvm-amd nested=y
@@ -97,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:
::
@@ -115,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
@@ -131,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.:
::
diff --git a/doc/source/guides/lxc.rst b/doc/source/guides/lxc.rst
new file mode 100644
index 0000000000..9549ed2974
--- /dev/null
+++ b/doc/source/guides/lxc.rst
@@ -0,0 +1,164 @@
+================================
+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 `
+ 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://git.openstack.org/openstack-dev/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).
diff --git a/doc/source/guides/multinode-lab.rst b/doc/source/guides/multinode-lab.rst
index b2617c9f17..b4e2891c10 100644
--- a/doc/source/guides/multinode-lab.rst
+++ b/doc/source/guides/multinode-lab.rst
@@ -73,8 +73,7 @@ Otherwise create the stack user:
::
- groupadd stack
- useradd -g stack -s /bin/bash -d /opt/stack -m stack
+ useradd -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
@@ -128,10 +127,9 @@ cluster controller's DevStack in ``local.conf``:
MULTI_HOST=1
LOGFILE=/opt/stack/logs/stack.sh.log
ADMIN_PASSWORD=labstack
- MYSQL_PASSWORD=supersecret
- RABBIT_PASSWORD=supersecrete
- SERVICE_PASSWORD=supersecrete
- SERVICE_TOKEN=xyzpdqlazydog
+ DATABASE_PASSWORD=supersecret
+ RABBIT_PASSWORD=supersecret
+ SERVICE_PASSWORD=supersecret
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
@@ -169,21 +167,25 @@ machines, create a ``local.conf`` with:
MULTI_HOST=1
LOGFILE=/opt/stack/logs/stack.sh.log
ADMIN_PASSWORD=labstack
- MYSQL_PASSWORD=supersecret
- RABBIT_PASSWORD=supersecrete
- SERVICE_PASSWORD=supersecrete
- SERVICE_TOKEN=xyzpdqlazydog
+ DATABASE_PASSWORD=supersecret
+ RABBIT_PASSWORD=supersecret
+ SERVICE_PASSWORD=supersecret
DATABASE_TYPE=mysql
SERVICE_HOST=192.168.42.11
- MYSQL_HOST=192.168.42.11
- RABBIT_HOST=192.168.42.11
- GLANCE_HOSTPORT=192.168.42.11:9292
- ENABLED_SERVICES=n-cpu,n-net,n-api,c-sch,c-api,c-vol
+ MYSQL_HOST=$SERVICE_HOST
+ RABBIT_HOST=$SERVICE_HOST
+ GLANCE_HOSTPORT=$SERVICE_HOST:9292
+ ENABLED_SERVICES=n-cpu,q-agt,n-api-meta,c-vol,placement-client
NOVA_VNC_ENABLED=True
- NOVNCPROXY_URL="http://192.168.42.11:6080/vnc_auto.html"
+ NOVNCPROXY_URL="http://$SERVICE_HOST:6080/vnc_auto.html"
VNCSERVER_LISTEN=$HOST_IP
VNCSERVER_PROXYCLIENT_ADDRESS=$VNCSERVER_LISTEN
+**Note:** the ``n-api-meta`` service is a version of the api server
+that only serves the metadata service. It's needed because the
+computes created won't have a routing path to the metadata service on
+the controller.
+
Fire up OpenStack:
::
@@ -195,6 +197,22 @@ 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
--------------------------
@@ -251,19 +269,19 @@ for scripting:
# Add a user and project
NAME=bob
- PASSWORD=BigSecrete
+ PASSWORD=BigSecret
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 list
+ # openstack role assignment list
Swift
-----
Swift, OpenStack Object Storage, requires a significant amount of resources
-and is disabled by default in DevStack. The support in DevStack is geared
+and is disabled by default in DevStack. The support in DevStack is geared
toward a minimal installation but can be used for testing. To implement a
true multi-node test of swift, additional steps will be required. Enabling it is as
simple as enabling the ``swift`` service in ``local.conf``:
@@ -291,10 +309,10 @@ created inside OpenStack. The size can be overridden by setting
``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`` in ``localrc``. ``stack.sh`` deletes all logical
-volumes in ``VOLUME_GROUP`` that begin with ``VOLUME_NAME_PREFIX`` as
+``VOLUME_GROUP_NAME`` in ``localrc``. ``stack.sh`` deletes all logical
+volumes in ``VOLUME_GROUP_NAME`` 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``.
+root volume group as ``VOLUME_GROUP_NAME``.
The details of creating the volume group depends on the server hardware
involved but looks something like this:
@@ -370,3 +388,47 @@ 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.pub 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
diff --git a/doc/source/guides/neutron.rst b/doc/source/guides/neutron.rst
index 3030c7b5f2..12c6d6902d 100644
--- a/doc/source/guides/neutron.rst
+++ b/doc/source/guides/neutron.rst
@@ -5,131 +5,251 @@ Using DevStack with neutron Networking
This guide will walk you through using OpenStack neutron with the ML2
plugin and the Open vSwitch mechanism driver.
-Network Interface Configuration
-===============================
-To use neutron, it is suggested that two network interfaces be present
-in the host operating system.
+.. _single-interface-ovs:
-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.
+Using Neutron with a Single Interface
+=====================================
-::
+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.
- stack@compute:~$ ifconfig eth0
- eth0 Link encap:Ethernet HWaddr bc:16:65:20:af:fc
- 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
-technique. For Ubuntu, the contents of `/etc/network/interfaces`
-contains:
+.. 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.
- auto eth1
- iface eth1 inet manual
- up ifconfig $IFACE 0.0.0.0 up
- down ifconfig $IFACE 0.0.0.0 down
-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.
+Physical Network Setup
+----------------------
-::
-
- stack@compute:~$ sudo ovs-vsctl add-br br-ex
- stack@compute:~$ sudo ovs-vsctl add-port br-ex eth1
- stack@compute:~$ sudo ovs-vsctl show
- 9a25c837-32ab-45f6-b9f2-1dd888abcf0f
- Bridge br-ex
- Port br-ex
- Interface br-ex
- type: internal
- Port phy-br-ex
- Interface phy-br-ex
- type: patch
- options: {peer=int-br-ex}
- Port "eth1"
- Interface "eth1"
+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.
+.. nwdiag::
+ nwdiag {
+ inet [ shape = cloud ];
+ router;
+ inet -- router;
+ network hardware_network {
+ address = "172.18.161.0/24"
+ router [ address = "172.18.161.1" ];
+ devstack-1 [ address = "172.18.161.6" ];
+ }
+ }
-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,
-but UDP and TCP packets will not be delivered to the guest VM. The root cause
-of the issue is that both ufw (Uncomplicated Firewall) and firewalld (Fedora's
-firewall manager) apply firewall rules to all interfaces in the system, rather
-then per-device. One solution to this problem is to revert to iptables
-functionality.
+DevStack Configuration
+----------------------
-To get a functional firewall configuration for Fedora do the following:
+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.
::
- sudo service iptables save
- sudo systemctl disable firewalld
- sudo systemctl enable iptables
- sudo systemctl stop firewalld
- sudo systemctl start iptables
+ [[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
+ ## Neutron options
+ Q_USE_SECGROUP=True
+ FLOATING_RANGE="172.18.161.0/24"
+ IPV4_ADDRS_SAFE_TO_USE="10.0.0.0/22"
+ Q_FLOATING_ALLOCATION_POOL=start=172.18.161.250,end=172.18.161.254
+ PUBLIC_NETWORK_GATEWAY="172.18.161.1"
+ 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
-To get a functional firewall configuration for distributions containing ufw,
-disable ufw. Note ufw is generally not enabled by default in Ubuntu. To
-disable ufw if it was enabled, do the following:
-::
+Adding Additional Compute Nodes
+-------------------------------
- sudo service iptables save
- sudo ufw disable
+Let's suppose that after installing DevStack on the first host, you
+also want to do multinode testing and networking.
+Physical Network Setup
+~~~~~~~~~~~~~~~~~~~~~~
+.. nwdiag::
+ nwdiag {
+ inet [ shape = cloud ];
+ router;
+ inet -- router;
-Neutron Networking with Open vSwitch
-====================================
+ network hardware_network {
+ address = "172.18.161.0/24"
+ router [ address = "172.18.161.1" ];
+ devstack-1 [ address = "172.18.161.6" ];
+ devstack-2 [ address = "172.18.161.7" ];
+ }
+ }
-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.
+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.
+::
-Configuration
--------------
+ 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.
::
- FIXED_RANGE=10.0.0.0/24
- FLOATING_RANGE=192.168.27.0/24
- PUBLIC_NETWORK_GATEWAY=192.168.27.2
+ 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`.
- 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_SECGROUP=True
- ENABLE_TENANT_VLANS=True
- TENANT_VLAN_RANGE=1000:1999
- PHYSICAL_NETWORK=default
- OVS_PHYSICAL_BRIDGE=br-ex
+ [[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.
-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.
Neutron Networking with Open vSwitch and Provider Networks
==========================================================
@@ -145,6 +265,76 @@ 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
+----------------------
+
+.. nwdiag::
+
+ nwdiag {
+ inet [ shape = cloud ];
+ router;
+ inet -- router;
+
+ network provider_net {
+ address = "203.0.113.0/24"
+ router [ address = "203.0.113.1" ];
+ controller;
+ compute1;
+ compute2;
+ }
+
+ network control_plane {
+ router [ address = "10.0.0.1" ]
+ address = "10.0.0.0/24"
+ controller [ address = "10.0.0.2" ]
+ compute1 [ address = "10.0.0.3" ]
+ compute2 [ address = "10.0.0.4" ]
+ }
+ }
+
+
+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.
+
+::
+
+ stack@compute:~$ ifconfig eth0
+ eth0 Link encap:Ethernet HWaddr bc:16:65:20:af:fc
+ inet addr:10.0.0.3
+
+eth1 is manually configured at boot to not have an IP address.
+Consult your operating system documentation for the appropriate
+technique. For Ubuntu, the contents of `/etc/network/interfaces`
+contains:
+
+::
+
+ auto eth1
+ iface eth1 inet manual
+ up ifconfig $IFACE 0.0.0.0 up
+ down ifconfig $IFACE 0.0.0.0 down
+
+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.
+
+::
+
+ stack@compute:~$ sudo ovs-vsctl add-br br-ex
+ stack@compute:~$ sudo ovs-vsctl add-port br-ex eth1
+ stack@compute:~$ sudo ovs-vsctl show
+ 9a25c837-32ab-45f6-b9f2-1dd888abcf0f
+ Bridge br-ex
+ Port br-ex
+ Interface br-ex
+ type: internal
+ Port phy-br-ex
+ Interface phy-br-ex
+ type: patch
+ options: {peer=int-br-ex}
+ Port "eth1"
+ Interface "eth1"
+
Service Configuration
---------------------
@@ -159,19 +349,31 @@ 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`.
+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
@@ -180,50 +382,253 @@ controller node.
OVS_PHYSICAL_BRIDGE=br-ex
Q_USE_PROVIDER_NETWORKING=True
- Q_L3_ENABLED=False
-
- # Do not use Nova-Network
- disable_service n-net
- # Neutron
- ENABLED_SERVICES+=,q-svc,q-dhcp,q-meta,q-agt
+ disable_service q-l3
## Neutron Networking options used to create Neutron Subnets
- FIXED_RANGE="10.1.1.0/24"
+ 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 FIXED_RANGE to be a
-subnet that exists in the private RFC1918 address space - however
-in a real setup FIXED_RANGE would be a public IP address range, so
-that you could access your instances from the public internet.
+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 `_,
+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 a snippet of the DevStack configuration on the
-compute node.
+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
- ## Neutron options
- Q_USE_SECGROUP=True
- ENABLE_TENANT_VLANS=True
- TENANT_VLAN_RANGE=3001:4000
+ ## Open vSwitch provider networking options
PHYSICAL_NETWORK=default
OVS_PHYSICAL_BRIDGE=br-ex
PUBLIC_INTERFACE=eth1
Q_USE_PROVIDER_NETWORKING=True
- Q_L3_ENABLED=False
+
+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 and `Q_L3_ENABLED` is False) -
+``Q_USE_PROVIDER_NETWORKING`` is True) -
DevStack will automatically add the network interface defined in
-`PUBLIC_INTERFACE` to the `OVS_PHYSICAL_BRIDGE`
+``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
+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,
+but UDP and TCP packets will not be delivered to the guest VM. The root cause
+of the issue is that both ufw (Uncomplicated Firewall) and firewalld (Fedora's
+firewall manager) apply firewall rules to all interfaces in the system, rather
+then per-device. One solution to this problem is to revert to iptables
+functionality.
+
+To get a functional firewall configuration for Fedora do the following:
+
+::
+
+ sudo service iptables save
+ sudo systemctl disable firewalld
+ sudo systemctl enable iptables
+ sudo systemctl stop firewalld
+ sudo systemctl start iptables
+
+
+To get a functional firewall configuration for distributions containing ufw,
+disable ufw. Note ufw is generally not enabled by default in Ubuntu. To
+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 `
+setup, with small modifications for the interface mappings.
+
+
+::
+
+ [[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
+
+ ## 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
+
+ Q_USE_PROVIDERNET_FOR_PUBLIC=True
+
+ # Linuxbridge Settings
+ Q_AGENT=linuxbridge
+ LB_PHYSICAL_INTERFACE=eth0
+ PUBLIC_PHYSICAL_NETWORK=default
+ LB_INTERFACE_MAPPINGS=default:eth0
+
+Using MacVTap instead of Open vSwitch
+------------------------------------------
+
+Security groups are not supported by the MacVTap agent. Due to that, devstack
+configures the NoopFirewall driver on the compute node.
+
+MacVTap agent does not support l3, dhcp and metadata agent. Due to that you can
+chose between the following deployment scenarios:
+
+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.
+
+
+::
+
+ [[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
+
+ Q_ML2_PLUGIN_MECHANISM_DRIVERS=macvtap
+ Q_USE_PROVIDER_NETWORKING=True
+
+ enable_plugin neutron git://git.openstack.org/openstack/neutron
+
+ ## MacVTap agent options
+ Q_AGENT=macvtap
+ PHYSICAL_NETWORK=default
+
+ 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
+
+ [[post-config|/$Q_PLUGIN_CONF_FILE]]
+ [macvtap]
+ physical_interface_mappings = $PHYSICAL_NETWORK:eth1
+
+ [[post-config|$NOVA_CONF]]
+ force_config_drive = True
+
+
+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 ` section can be
+used. Just add the following line to this local.conf, which also loads
+the MacVTap mechanism driver:
+
+::
+
+ [[local|localrc]]
+ ...
+ Q_ML2_PLUGIN_MECHANISM_DRIVERS=openvswitch,linuxbridge,macvtap
+ ...
+
+For the MacVTap compute node, use this local.conf:
+
+::
+
+ 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 git://git.openstack.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
diff --git a/doc/source/guides/nova.rst b/doc/source/guides/nova.rst
index a91e0d194c..0f105d7c58 100644
--- a/doc/source/guides/nova.rst
+++ b/doc/source/guides/nova.rst
@@ -13,7 +13,7 @@ In Juno, nova implemented a `spec
`_
to allow read/write access to the serial console of an instance via
`nova-serialproxy
-`_.
+`_.
The service can be enabled by adding ``n-sproxy`` to
``ENABLED_SERVICES``. Further options can be enabled via
@@ -62,11 +62,9 @@ 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.console.serial
-`_
-and `nova.cmd.serialproxy
-`_.
+These config options are defined in `nova.conf.serial_console
+`_.
For more information on OpenStack configuration see the `OpenStack
-Configuration Reference
-`_
+Compute Service Configuration Reference
+`_
diff --git a/doc/source/guides/single-machine.rst b/doc/source/guides/single-machine.rst
index 236ece9c01..168172c630 100644
--- a/doc/source/guides/single-machine.rst
+++ b/doc/source/guides/single-machine.rst
@@ -45,31 +45,37 @@ 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
- adduser stack
+ $ sudo useradd -s /bin/bash -d /opt/stack -m 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" >> /etc/sudoers
+ $ apt-get install sudo -y || yum install -y sudo
+ $ echo "stack ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers
+
+.. note:: On some systems you may need to use ``sudo visudo``.
From here on you should use the user you created. **Logout** and
-**login** as that user.
+**login** as that user:
+
+.. code-block:: console
+
+ $ sudo su stack && cd ~
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://git.openstack.org/openstack-dev/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
------------
@@ -97,7 +103,7 @@ do the following:
``local.conf`` should look something like this:
-::
+.. code-block:: ini
[[local|localrc]]
FLOATING_RANGE=192.168.1.224/27
@@ -105,16 +111,18 @@ do the following:
FIXED_NETWORK_SIZE=256
FLAT_INTERFACE=eth0
ADMIN_PASSWORD=supersecret
- MYSQL_PASSWORD=iheartdatabases
+ DATABASE_PASSWORD=iheartdatabases
RABBIT_PASSWORD=flopsymopsy
SERVICE_PASSWORD=iheartksl
- SERVICE_TOKEN=xyzpdqlazydog
+
+.. note:: There is a sample :download:`local.conf ` file
+ under the *samples* directory in the devstack repository.
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,
@@ -128,7 +136,3 @@ 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.
diff --git a/doc/source/guides/single-vm.rst b/doc/source/guides/single-vm.rst
index c2ce1a34a0..45b8f2dd89 100644
--- a/doc/source/guides/single-vm.rst
+++ b/doc/source/guides/single-vm.rst
@@ -64,10 +64,9 @@ passed as the user-data file when booting the VM.
cd devstack
echo '[[local|localrc]]' > local.conf
echo ADMIN_PASSWORD=password >> local.conf
- echo MYSQL_PASSWORD=password >> local.conf
+ echo DATABASE_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,6 +77,11 @@ passed as the user-data file when booting the VM.
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
+`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.
+
Launching By Hand
-----------------
diff --git a/doc/source/index.rst b/doc/source/index.rst
index e0c3f3a5d6..6c42a5b4e9 100644
--- a/doc/source/index.rst
+++ b/doc/source/index.rst
@@ -1,244 +1,162 @@
-DevStack - an OpenStack Community Production
-============================================
+.. Documentation Architecture for the devstack docs.
-.. image:: assets/images/logo-blue.png
-
-.. toctree::
- :glob:
- :maxdepth: 1
-
- overview
- configuration
- plugins
- faq
- changes
- hacking
-
-Quick Start
------------
+ 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.
-#. Select a Linux Distribution
+ 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.
- Only Ubuntu 14.04 (Trusty), Fedora 20 and CentOS/RHEL 7 are
- documented here. OpenStack also runs and is packaged on other flavors
- of Linux such as OpenSUSE and Debian.
+==========
+ DevStack
+==========
-#. Install Selected OS
+.. image:: assets/images/logo-blue.png
- 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 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.
-#. Download DevStack
+The source is available at
+``__.
- ::
+.. warning::
- git clone https://git.openstack.org/openstack-dev/devstack
+ DevStack will make substantial changes to your system during
+ installation. Only run DevStack on servers or virtual machines that
+ are dedicated to this purpose.
- The ``devstack`` repo contains a script that installs OpenStack and
- templates for configuration files
+Quick Start
+===========
-#. Configure
+Install Linux
+-------------
- We recommend at least a :ref:`minimal-configuration` be set up.
+Start with a clean and minimal install of a Linux system. Devstack
+attempts to support the two latest LTS releases of Ubuntu, the
+latest/current Fedora version, CentOS/RHEL 7, as well as Debian and
+OpenSUSE.
-#. Start the install
+If you do not have a preference, Ubuntu 16.04 is the most tested, and
+will probably go the smoothest.
- ::
+Add Stack User
+--------------
- cd devstack; ./stack.sh
+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).
- It takes a few minutes, we recommend `reading the
- script `__ while it is building.
+You can quickly create a separate `stack` user to run DevStack with
-Guides
-======
+.. code-block:: console
-Walk through various setups used by stackers
+ $ sudo useradd -s /bin/bash -d /opt/stack -m stack
-.. toctree::
- :glob:
- :maxdepth: 1
+Since this user will be making many changes to your system, it should
+have sudo privileges:
- guides/single-vm
- guides/single-machine
- guides/multinode-lab
- guides/neutron
- guides/devstack-with-nested-kvm
- guides/nova
- guides/devstack-with-lbaas-v2
+.. code-block:: console
-All-In-One Single VM
---------------------
+ $ echo "stack ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/stack
+ $ sudo su - stack
-Run :doc:`OpenStack in a 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] `
+Download DevStack
+-----------------
-All-In-One Single Machine
--------------------------
+.. code-block:: console
-Run :doc:`OpenStack on dedicated hardware ` This can include a
-server-class machine or a laptop at home.
-:doc:`[Read] `
+ $ git clone https://git.openstack.org/openstack-dev/devstack
+ $ cd devstack
-Multi-Node Lab
---------------
+The ``devstack`` repo contains a script that installs OpenStack and
+templates for configuration files
-Setup a :doc:`multi-node cluster ` with dedicated VLANs for VMs & Management.
-:doc:`[Read] `
+Create a local.conf
+-------------------
-DevStack with Neutron Networking
---------------------------------
+Create a ``local.conf`` file with 4 passwords preset at the root of the
+devstack git repo.
-Building a DevStack cluster with :doc:`Neutron Networking `.
-This guide is meant for building lab environments with a dedicated
-control node and multiple compute nodes.
+.. code-block:: ini
-DevStack with KVM-based Nested Virtualization
----------------------------------------------
+ [[local|localrc]]
+ ADMIN_PASSWORD=secret
+ DATABASE_PASSWORD=$ADMIN_PASSWORD
+ RABBIT_PASSWORD=$ADMIN_PASSWORD
+ SERVICE_PASSWORD=$ADMIN_PASSWORD
-Procedure to setup :doc:`DevStack with KVM-based Nested Virtualization
-`. With this setup, Nova instances
-will be more performant than with plain QEMU emulation.
+This is the minimum required config to get started with DevStack.
-Nova and devstack
---------------------------------
+.. note:: There is a sample :download:`local.conf ` file
+ under the *samples* directory in the devstack repository.
-Guide to working with nova features :doc:`Nova and devstack `.
+Start the install
+-----------------
-DevStack Documentation
-======================
+.. code-block:: console
-Overview
---------
+ $ ./stack.sh
-:doc:`An overview of DevStack goals and priorities `
+This will take a 15 - 20 minutes, largely depending on the speed of
+your internet connection. Many git trees and packages will be
+installed during this process.
-Configuration
--------------
+Profit!
+-------
-:doc:`Configuring and customizing the stack `
+You now have a working DevStack! Congrats!
-Plugins
--------
+Your devstack will have installed ``keystone``, ``glance``, ``nova``,
+``cinder``, ``neutron``, and ``horizon``. Floating IPs will be
+available, guests have access to the external world.
-:doc:`Extending DevStack with new features `
+You can access horizon to experience the web interface to
+OpenStack, and manage vms, networks, volumes, and images from
+there.
-Recent Changes
---------------
+You can ``source openrc`` in your shell, and then use the
+``openstack`` command line tool to manage your devstack.
-:doc:`An incomplete summary of recent changes `
+You can ``cd /opt/stack/tempest`` and run tempest tests that have
+been configured to work with your devstack.
-FAQ
----
+You can :doc:`make code changes to OpenStack and validate them
+`.
-:doc:`The DevStack FAQ `
+Going further
+-------------
-Contributing
-------------
+Learn more about our :doc:`configuration system ` to
+customize devstack for your needs. Including making adjustments to the
+default :doc:`networking `.
-:doc:`Pitching in to make DevStack a better place `
+Read :doc:`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).
-Code
-====
+Enable :doc:`devstack plugins ` to support additional
+services, features, and configuration not present in base devstack.
-*A look at the bits that make it all go*
+Use devstack in your CI with :doc:`Ansible roles ` and
+:doc:`Jobs ` for Zuul V3. Migrate your devstack Zuul V2 jobs to Zuul
+V3 with this full migration :doc:`how-to `.
-Scripts
--------
+Get :doc:`the big picture ` of what we are trying to do
+with devstack, and help us by :doc:`contributing to the project
+`.
-* `stack.sh `__ - The main script
-* `functions `__ - DevStack-specific functions
-* `functions-common `__ - Functions shared with other projects
-* `lib/apache `__
-* `lib/ceilometer `__
-* `lib/ceph `__
-* `lib/cinder `__
-* `lib/database `__
-* `lib/dstat `__
-* `lib/glance `__
-* `lib/heat `__
-* `lib/horizon `__
-* `lib/infra `__
-* `lib/ironic `__
-* `lib/keystone `__
-* `lib/ldap `__
-* `lib/neutron-legacy `__
-* `lib/nova `__
-* `lib/oslo `__
-* `lib/rpc\_backend `__
-* `lib/sahara `__
-* `lib/swift `__
-* `lib/tempest `__
-* `lib/tls `__
-* `lib/zaqar `__
-* `unstack.sh `__
-* `clean.sh `__
-* `run\_tests.sh `__
-
-* `extras.d/50-ironic.sh `__
-* `extras.d/60-ceph.sh `__
-* `extras.d/70-sahara.sh `__
-* `extras.d/70-tuskar.sh `__
-* `extras.d/70-zaqar.sh `__
-* `extras.d/80-tempest.sh `__
-
-* `inc/ini-config `__
-* `inc/meta-config `__
-* `inc/python `__
-
-* `pkg/elasticsearch.sh `_
-
-Configuration
--------------
+Contents
+--------
.. toctree::
:glob:
- :maxdepth: 1
-
- local.conf
- stackrc
- openrc
- exerciserc
- eucarc
-
-Tools
------
-
-* `tools/build\_docs.sh `__
-* `tools/build\_venv.sh `__
-* `tools/build\_wheels.sh `__
-* `tools/create-stack-user.sh `__
-* `tools/create\_userrc.sh `__
-* `tools/fixup\_stuff.sh `__
-* `tools/info.sh `__
-* `tools/install\_pip.sh `__
-* `tools/install\_prereqs.sh `__
-* `tools/make\_cert.sh `__
-* `tools/upload\_image.sh `__
-
-Samples
--------
+ :maxdepth: 2
-* `local.sh `__
-
-Exercises
----------
-
-* `exercise.sh `__
-* `exercises/aggregates.sh `__
-* `exercises/boot\_from\_volume.sh `__
-* `exercises/bundle.sh `__
-* `exercises/client-args.sh `__
-* `exercises/client-env.sh `__
-* `exercises/euca.sh `__
-* `exercises/floating\_ips.sh `__
-* `exercises/horizon.sh `__
-* `exercises/neutron-adv-test.sh `__
-* `exercises/sahara.sh `__
-* `exercises/sec\_groups.sh `__
-* `exercises/swift.sh `__
-* `exercises/volumes.sh `__
-* `exercises/zaqar.sh `__
+ *
diff --git a/doc/source/local.conf.rst b/doc/source/local.conf.rst
deleted file mode 100644
index a1ca60a75d..0000000000
--- a/doc/source/local.conf.rst
+++ /dev/null
@@ -1,9 +0,0 @@
-==========================
-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 ` for more details about the mechanics
-of the file.
diff --git a/doc/source/networking.rst b/doc/source/networking.rst
new file mode 100644
index 0000000000..74010cd01a
--- /dev/null
+++ b/doc/source/networking.rst
@@ -0,0 +1,116 @@
+=====================
+ 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 you 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.52/24
+ PUBLIC_NETWORK_GATEWAY=10.42.0.1
+ Q_FLOATING_ALLOCATION_POOL=start=10.42.0.250,end=10.42.0.254
+
+In order for this scenario to work the floating ip network must match
+the default networking on your server. This breaks HOST_IP detection,
+as we exclude the floating range by default, so you have to specify
+that manually.
+
+The ``PUBLIC_NETWORK_GATEWAY`` is the gateway that server would normally
+use to get off the network. ``Q_FLOATING_ALLOCATION_POOL`` controls
+the range of floating ips that will be handed out. As we are sharing
+your existing network, you'll want to give it a slice that your local
+dhcp server is not allocating. Otherwise you could easily have
+conflicting ip addresses, and cause havoc with your local network.
+
+
+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.
diff --git a/doc/source/openrc.rst b/doc/source/openrc.rst
deleted file mode 100644
index 0b090c77b7..0000000000
--- a/doc/source/openrc.rst
+++ /dev/null
@@ -1,68 +0,0 @@
-=====================================
-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
diff --git a/doc/source/overview.rst b/doc/source/overview.rst
index d245035a1a..2479cd0bc8 100644
--- a/doc/source/overview.rst
+++ b/doc/source/overview.rst
@@ -20,11 +20,11 @@ Base OS
*The OpenStack Technical Committee (TC) has defined the current CI
strategy to include the latest Ubuntu release and the latest RHEL
-release (for Python 2.6 testing).*
+release.*
- Ubuntu: current LTS release plus current development release
- Fedora: current release plus previous release
-- RHEL: current major release
+- RHEL/CentOS: 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
@@ -38,7 +38,6 @@ Databases
*As packaged by the host OS*
- MySQL
-- PostgreSQL
Queues
------
@@ -46,7 +45,6 @@ Queues
*As packaged by the host OS*
- Rabbit
-- Qpid
Web Server
----------
@@ -58,9 +56,6 @@ 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.
@@ -68,9 +63,8 @@ Services
--------
The default services configured by DevStack are Identity (keystone),
-Object Storage (swift), Image Service (glance), Block Storage (cinder),
-Compute (nova), Networking (nova), Dashboard (horizon), Orchestration
-(heat)
+Object Storage (swift), Image Service (glance), Block Storage
+(cinder), Compute (nova), Networking (neutron), Dashboard (horizon)
Additional services not included directly in DevStack can be tied in to
``stack.sh`` using the :doc:`plugin mechanism ` to call
@@ -80,13 +74,4 @@ Node Configurations
-------------------
- single node
-- 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.
+- multi-node configurations as are tested by the gate
diff --git a/doc/source/plugin-registry.rst b/doc/source/plugin-registry.rst
new file mode 100644
index 0000000000..02d6911d4b
--- /dev/null
+++ b/doc/source/plugin-registry.rst
@@ -0,0 +1,202 @@
+.. 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.
+
+
+====================================== ===
+Plugin Name URL
+====================================== ===
+almanach `git://git.openstack.org/openstack/almanach `__
+aodh `git://git.openstack.org/openstack/aodh `__
+apmec `git://git.openstack.org/openstack/apmec `__
+barbican `git://git.openstack.org/openstack/barbican `__
+bilean `git://git.openstack.org/openstack/bilean `__
+blazar `git://git.openstack.org/openstack/blazar `__
+broadview-collector `git://git.openstack.org/openstack/broadview-collector `__
+castellan-ui `git://git.openstack.org/openstack/castellan-ui `__
+ceilometer `git://git.openstack.org/openstack/ceilometer `__
+ceilometer-powervm `git://git.openstack.org/openstack/ceilometer-powervm `__
+cloudkitty `git://git.openstack.org/openstack/cloudkitty `__
+collectd-openstack-plugins `git://git.openstack.org/openstack/collectd-openstack-plugins `__
+congress `git://git.openstack.org/openstack/congress `__
+cyborg `git://git.openstack.org/openstack/cyborg `__
+designate `git://git.openstack.org/openstack/designate `__
+devstack-plugin-additional-pkg-repos `git://git.openstack.org/openstack/devstack-plugin-additional-pkg-repos `__
+devstack-plugin-amqp1 `git://git.openstack.org/openstack/devstack-plugin-amqp1 `__
+devstack-plugin-bdd `git://git.openstack.org/openstack/devstack-plugin-bdd `__
+devstack-plugin-ceph `git://git.openstack.org/openstack/devstack-plugin-ceph `__
+devstack-plugin-container `git://git.openstack.org/openstack/devstack-plugin-container `__
+devstack-plugin-glusterfs `git://git.openstack.org/openstack/devstack-plugin-glusterfs `__
+devstack-plugin-hdfs `git://git.openstack.org/openstack/devstack-plugin-hdfs `__
+devstack-plugin-kafka `git://git.openstack.org/openstack/devstack-plugin-kafka `__
+devstack-plugin-libvirt-qemu `git://git.openstack.org/openstack/devstack-plugin-libvirt-qemu `__
+devstack-plugin-mariadb `git://git.openstack.org/openstack/devstack-plugin-mariadb `__
+devstack-plugin-nfs `git://git.openstack.org/openstack/devstack-plugin-nfs `__
+devstack-plugin-pika `git://git.openstack.org/openstack/devstack-plugin-pika `__
+devstack-plugin-sheepdog `git://git.openstack.org/openstack/devstack-plugin-sheepdog `__
+devstack-plugin-vmax `git://git.openstack.org/openstack/devstack-plugin-vmax `__
+devstack-plugin-zmq `git://git.openstack.org/openstack/devstack-plugin-zmq `__
+dragonflow `git://git.openstack.org/openstack/dragonflow `__
+drbd-devstack `git://git.openstack.org/openstack/drbd-devstack `__
+ec2-api `git://git.openstack.org/openstack/ec2-api `__
+freezer `git://git.openstack.org/openstack/freezer `__
+freezer-api `git://git.openstack.org/openstack/freezer-api `__
+freezer-tempest-plugin `git://git.openstack.org/openstack/freezer-tempest-plugin `__
+freezer-web-ui `git://git.openstack.org/openstack/freezer-web-ui `__
+gce-api `git://git.openstack.org/openstack/gce-api `__
+glare `git://git.openstack.org/openstack/glare `__
+group-based-policy `git://git.openstack.org/openstack/group-based-policy `__
+gyan `git://git.openstack.org/openstack/gyan `__
+heat `git://git.openstack.org/openstack/heat `__
+heat-dashboard `git://git.openstack.org/openstack/heat-dashboard `__
+horizon-mellanox `git://git.openstack.org/openstack/horizon-mellanox `__
+ironic `git://git.openstack.org/openstack/ironic `__
+ironic-inspector `git://git.openstack.org/openstack/ironic-inspector `__
+ironic-staging-drivers `git://git.openstack.org/openstack/ironic-staging-drivers `__
+ironic-ui `git://git.openstack.org/openstack/ironic-ui `__
+karbor `git://git.openstack.org/openstack/karbor `__
+karbor-dashboard `git://git.openstack.org/openstack/karbor-dashboard `__
+keystone `git://git.openstack.org/openstack/keystone `__
+kingbird `git://git.openstack.org/openstack/kingbird `__
+kuryr-kubernetes `git://git.openstack.org/openstack/kuryr-kubernetes `__
+kuryr-libnetwork `git://git.openstack.org/openstack/kuryr-libnetwork `__
+kuryr-tempest-plugin `git://git.openstack.org/openstack/kuryr-tempest-plugin `__
+magnum `git://git.openstack.org/openstack/magnum `__
+magnum-ui `git://git.openstack.org/openstack/magnum-ui `__
+manila `git://git.openstack.org/openstack/manila `__
+manila-ui `git://git.openstack.org/openstack/manila-ui `__
+masakari `git://git.openstack.org/openstack/masakari `__
+meteos `git://git.openstack.org/openstack/meteos `__
+meteos-ui `git://git.openstack.org/openstack/meteos-ui `__
+mistral `git://git.openstack.org/openstack/mistral `__
+mixmatch `git://git.openstack.org/openstack/mixmatch `__
+mogan `git://git.openstack.org/openstack/mogan `__
+mogan-ui `git://git.openstack.org/openstack/mogan-ui `__
+monasca-analytics `git://git.openstack.org/openstack/monasca-analytics `__
+monasca-api `git://git.openstack.org/openstack/monasca-api `__
+monasca-ceilometer `git://git.openstack.org/openstack/monasca-ceilometer `__
+monasca-events-api `git://git.openstack.org/openstack/monasca-events-api `__
+monasca-log-api `git://git.openstack.org/openstack/monasca-log-api `__
+monasca-tempest-plugin `git://git.openstack.org/openstack/monasca-tempest-plugin `__
+monasca-transform `git://git.openstack.org/openstack/monasca-transform `__
+murano `git://git.openstack.org/openstack/murano `__
+networking-6wind `git://git.openstack.org/openstack/networking-6wind `__
+networking-ansible `git://git.openstack.org/openstack/networking-ansible `__
+networking-arista `git://git.openstack.org/openstack/networking-arista `__
+networking-bagpipe `git://git.openstack.org/openstack/networking-bagpipe `__
+networking-baremetal `git://git.openstack.org/openstack/networking-baremetal `__
+networking-bgpvpn `git://git.openstack.org/openstack/networking-bgpvpn `__
+networking-brocade `git://git.openstack.org/openstack/networking-brocade `__
+networking-calico `git://git.openstack.org/openstack/networking-calico `__
+networking-cisco `git://git.openstack.org/openstack/networking-cisco `__
+networking-cumulus `git://git.openstack.org/openstack/networking-cumulus `__
+networking-dpm `git://git.openstack.org/openstack/networking-dpm `__
+networking-fortinet `git://git.openstack.org/openstack/networking-fortinet `__
+networking-generic-switch `git://git.openstack.org/openstack/networking-generic-switch `__
+networking-hpe `git://git.openstack.org/openstack/networking-hpe `__
+networking-huawei `git://git.openstack.org/openstack/networking-huawei `__
+networking-hyperv `git://git.openstack.org/openstack/networking-hyperv `__
+networking-infoblox `git://git.openstack.org/openstack/networking-infoblox `__
+networking-l2gw `git://git.openstack.org/openstack/networking-l2gw