Files
4423450eb334aad6f889ddae2ab9b9a2a2197a4a
devstack /doc /source /configuration.rst

768 lines
23 KiB
ReStructuredText
Raw Normal View History

=============
Configuration
=============
.. contents::
:local:
:depth: 1
local.conf
==========
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:
::
'[[' <phase> '|' <config-file-name> ']]'
where ``<phase>`` is one of a set of phase names defined by ``stack.sh``
and ``<config-file-name>`` 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
- **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
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``
Remove shocco docs and other cleanups This is a fairly opinionated change to do some spring cleaning on the documentation. The current output of shocco as rendered at [1] is completely broken. I can not see that it is worth us maintaining this. Honestly, the github page does a better job at showing the scripts with a bit of formatting. The "changes" page is similarly useless today. cgit or github show allow browsing of changes in the repo better. Both are removed along with support scripts. When you currently hit the first page, it gives no clue as to what DevStack actually is. Add a paragraph explaining that, and link to the cgit for easy source browsing. stackrc.rst is not necessary; the stuff about database backends is already discussed in configuration.rst; move the things about service repos into a section of configuration.rst. The discussion in openrc.rst is moved into the configuration.rst file. localrc.conf.rst was just a paragraph pointing back to configuration.rst; this is removed. The variables described in exercise.rst are moved into a separate section of configuration.rst [1] http://docs.openstack.org/developer/devstack/#scripts Change-Id: Ie7f4b265368f1d10a8908d75e11d625b2cc39e7c
2016年04月08日 09:40:56 +10:00
exists it will be used instead to preserve backward-compatibility.
::
[[local|localrc]]
Derive IP ranges from new ADDRS_SAFE_TO_USE vars The switch to using subnetpools caused quite a bit of confusion because it didn't respect the value of FIXED_RANGE. This caused conflicts in the gate with it's default IPv4 value of 10.0.0.0/8. This patch does a few things to address the issue: * It introduces the IPV4_ADDRS_SAFE_TO_USE and IPV6_ADDRS_SAFE_TO_USE values and adjusts all of the FIXED_RANGE and SUBNETPOOL_PREFIX values to dervive from them by default. * This addresses the concern that was raised about implying that SUBNETPOOL_PREFIX and FIXED_RANGE are equivalent when setting SUBNETPOOL_PREFIX=FIXED_RANGE by default. Now we have a new value for the operator specify a chunk of addresses that are safe to use for private networks without implementation implications. * Backwards compatibility is maintained by alloing users to override override all of these values. * The default for IPV4_ADDRS_SAFE_TO_USE uses /22 instead of /24 * Because we want to be able to use subnetpools for auto allocated topologies and we want to be able to have a large chunk of instances on each network, we needed a little more breathing room in the default v4 network size. * SUBNET_POOL_SIZE_V4 default is changed from 24 to 26 * In conjuction with this change and the one above, the default subnetpool will support up to 16 64-address allocations. * This should be enough to cover any regular gate scenarios. * If someone wants a bigger/smaller subnet, they can ask for that in the API request, change this value themselves, or use a different network entirely. * FIXED_RANGE_V6 defaults to a max prefix of /64 from IPV6_ADDRS_SAFE_TO_USE * This avoids the private subnet in the non-subnetpool case from being larger than /64 to avoid issues identified in rfc 7421. * Users can still explicitly set this value to whatever they want. This 'max' behavior is only for the default. * This allows IPV6_ADDRS_SAFE_TO_USE to default to a /56, which leaves tons of room for v6 subnetpools. Closes-Bug: #1629133 Change-Id: I7b32804d47bec743c0b13e434e6a7958728896ea
2016年11月15日 17:26:05 -08:00
IPV4_ADDRS_SAFE_TO_USE=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]]
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).
Remove shocco docs and other cleanups This is a fairly opinionated change to do some spring cleaning on the documentation. The current output of shocco as rendered at [1] is completely broken. I can not see that it is worth us maintaining this. Honestly, the github page does a better job at showing the scripts with a bit of formatting. The "changes" page is similarly useless today. cgit or github show allow browsing of changes in the repo better. Both are removed along with support scripts. When you currently hit the first page, it gives no clue as to what DevStack actually is. Add a paragraph explaining that, and link to the cgit for easy source browsing. stackrc.rst is not necessary; the stuff about database backends is already discussed in configuration.rst; move the things about service repos into a section of configuration.rst. The discussion in openrc.rst is moved into the configuration.rst file. localrc.conf.rst was just a paragraph pointing back to configuration.rst; this is removed. The variables described in exercise.rst are moved into a separate section of configuration.rst [1] http://docs.openstack.org/developer/devstack/#scripts Change-Id: Ie7f4b265368f1d10a8908d75e11d625b2cc39e7c
2016年04月08日 09:40:56 +10:00
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
Remove shocco docs and other cleanups This is a fairly opinionated change to do some spring cleaning on the documentation. The current output of shocco as rendered at [1] is completely broken. I can not see that it is worth us maintaining this. Honestly, the github page does a better job at showing the scripts with a bit of formatting. The "changes" page is similarly useless today. cgit or github show allow browsing of changes in the repo better. Both are removed along with support scripts. When you currently hit the first page, it gives no clue as to what DevStack actually is. Add a paragraph explaining that, and link to the cgit for easy source browsing. stackrc.rst is not necessary; the stuff about database backends is already discussed in configuration.rst; move the things about service repos into a section of configuration.rst. The discussion in openrc.rst is moved into the configuration.rst file. localrc.conf.rst was just a paragraph pointing back to configuration.rst; this is removed. The variables described in exercise.rst are moved into a separate section of configuration.rst [1] http://docs.openstack.org/developer/devstack/#scripts Change-Id: Ie7f4b265368f1d10a8908d75e11d625b2cc39e7c
2016年04月08日 09:40:56 +10:00
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
Add a target for, and link to, minimal config docs Reading through the docs for the first time, the reader encounters an instruction to provide a minimal configuration, with a link that they'd expect to tell them how to do this. At present the link actually takes them to the top of configuration.html, where they read some history about how devstack's configuration has changed over time. This is interesting and important and should be in the docs - but in my opinion a link about setting up a minimal configuration would be more useful if it takes me to a place that tells them about a minimal configuration. To get this, I've had to an an explicit link target into configuration.rst. I'm not hugely keen on this approach, as I don't think it scales well. I'd be open to suggestions about other approaches. The only idea I've had so far though is to simply move the minimal configuration section right to the top of the page, so that a link to the doc is a link to the minimal config - the historical information could be moved to its own topic somewhere further down the doc. Change-Id: I231ca1b7f17b55f09a4e058dab8ee433893f737e
2015年03月30日 17:36:26 +11:00
.. _minimal-configuration:
Minimal Configuration
=====================
While ``stack.sh`` is happy to run without a ``localrc`` section in
``local.conf``, devlife is better when there are a few minimal variables
set. This is an example of a minimal configuration that touches the
values that most often need to be set.
- no logging
- pre-set the passwords to prevent interactive prompts
Derive IP ranges from new ADDRS_SAFE_TO_USE vars The switch to using subnetpools caused quite a bit of confusion because it didn't respect the value of FIXED_RANGE. This caused conflicts in the gate with it's default IPv4 value of 10.0.0.0/8. This patch does a few things to address the issue: * It introduces the IPV4_ADDRS_SAFE_TO_USE and IPV6_ADDRS_SAFE_TO_USE values and adjusts all of the FIXED_RANGE and SUBNETPOOL_PREFIX values to dervive from them by default. * This addresses the concern that was raised about implying that SUBNETPOOL_PREFIX and FIXED_RANGE are equivalent when setting SUBNETPOOL_PREFIX=FIXED_RANGE by default. Now we have a new value for the operator specify a chunk of addresses that are safe to use for private networks without implementation implications. * Backwards compatibility is maintained by alloing users to override override all of these values. * The default for IPV4_ADDRS_SAFE_TO_USE uses /22 instead of /24 * Because we want to be able to use subnetpools for auto allocated topologies and we want to be able to have a large chunk of instances on each network, we needed a little more breathing room in the default v4 network size. * SUBNET_POOL_SIZE_V4 default is changed from 24 to 26 * In conjuction with this change and the one above, the default subnetpool will support up to 16 64-address allocations. * This should be enough to cover any regular gate scenarios. * If someone wants a bigger/smaller subnet, they can ask for that in the API request, change this value themselves, or use a different network entirely. * FIXED_RANGE_V6 defaults to a max prefix of /64 from IPV6_ADDRS_SAFE_TO_USE * This avoids the private subnet in the non-subnetpool case from being larger than /64 to avoid issues identified in rfc 7421. * Users can still explicitly set this value to whatever they want. This 'max' behavior is only for the default. * This allows IPV6_ADDRS_SAFE_TO_USE to default to a /56, which leaves tons of room for v6 subnetpools. Closes-Bug: #1629133 Change-Id: I7b32804d47bec743c0b13e434e6a7958728896ea
2016年11月15日 17:26:05 -08:00
- 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=secret
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
Derive IP ranges from new ADDRS_SAFE_TO_USE vars The switch to using subnetpools caused quite a bit of confusion because it didn't respect the value of FIXED_RANGE. This caused conflicts in the gate with it's default IPv4 value of 10.0.0.0/8. This patch does a few things to address the issue: * It introduces the IPV4_ADDRS_SAFE_TO_USE and IPV6_ADDRS_SAFE_TO_USE values and adjusts all of the FIXED_RANGE and SUBNETPOOL_PREFIX values to dervive from them by default. * This addresses the concern that was raised about implying that SUBNETPOOL_PREFIX and FIXED_RANGE are equivalent when setting SUBNETPOOL_PREFIX=FIXED_RANGE by default. Now we have a new value for the operator specify a chunk of addresses that are safe to use for private networks without implementation implications. * Backwards compatibility is maintained by alloing users to override override all of these values. * The default for IPV4_ADDRS_SAFE_TO_USE uses /22 instead of /24 * Because we want to be able to use subnetpools for auto allocated topologies and we want to be able to have a large chunk of instances on each network, we needed a little more breathing room in the default v4 network size. * SUBNET_POOL_SIZE_V4 default is changed from 24 to 26 * In conjuction with this change and the one above, the default subnetpool will support up to 16 64-address allocations. * This should be enough to cover any regular gate scenarios. * If someone wants a bigger/smaller subnet, they can ask for that in the API request, change this value themselves, or use a different network entirely. * FIXED_RANGE_V6 defaults to a max prefix of /64 from IPV6_ADDRS_SAFE_TO_USE * This avoids the private subnet in the non-subnetpool case from being larger than /64 to avoid issues identified in rfc 7421. * Users can still explicitly set this value to whatever they want. This 'max' behavior is only for the default. * This allows IPV6_ADDRS_SAFE_TO_USE to default to a /56, which leaves tons of room for v6 subnetpools. Closes-Bug: #1629133 Change-Id: I7b32804d47bec743c0b13e434e6a7958728896ea
2016年11月15日 17:26:05 -08:00
#IPV4_ADDRS_SAFE_TO_USE=172.31.1.0/24
#FLOATING_RANGE=192.168.20.0/25
#HOST_IP=10.3.4.5
If the ``*_PASSWORD`` variables are not set here you will be prompted to
enter values for them by ``stack.sh``.
The network ranges must not overlap with any networks in use on the
host. Overlap is not uncommon as RFC-1918 'private' ranges are commonly
used for both the local networking and Nova's fixed and floating ranges.
``HOST_IP`` is normally detected on the first run of ``stack.sh`` but
often is indeterminate on later runs due to the IP being moved from an
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.
Add IPv6 support to devstack infrastructure By default, most Openstack services are bound to 0.0.0.0 and service endpoints are registered as IPv4 addresses. With this change we introduce two new variables to control this behavior: SERVICE_IP_VERSION - can either be "4" or "6". When set to "4" (default if not set) devstack will operate as today - most services will open listen sockets on 0.0.0.0 and service endpoints will be registered using HOST_IP as the address. When set to "6" devstack services will open listen sockets on :: and service endpoints will be registered using HOST_IPV6 as the address. There is no support for "4+6", more work is required for that. HOST_IPV6 - if SERVICE_IP_VERSION=6 this must be an IPv6 address configured on the system. Some existing services, like the Openvswitch agent, will continue to use IPv4 addresses for things like tunnel endpoints. This is a current restriction in the code and can be updated at a later time. This change is just a first step to supporting IPv6-only control and data planes in devstack. This change is also partly based on two previous patches, https://review.openstack.org/#/c/140519/ and https://review.openstack.org/#/c/176898/ Change-Id: I5c0b775490ce54ab104fd5e89b20fb700212ae74 Co-Authored-By: Sean Collins <sean@coreitpro.com> Co-Authored-By: Baodong Li <baoli@cisco.com> Co-Authored-By: Sridhar Gaddam <sridhar.gaddam@enovance.com> Co-Authored-By: Adam Kacmarsky <adam.kacmarsky@hp.com> Co-Authored-By: Jeremy Alvis <jeremy.alvis@hp.com>
2015年06月16日 13:14:31 -04:00
``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.
For architecture specific configurations which differ from the x86 default
here, see `arch-configuration`_.
Historical Notes
================
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
Historically DevStack obtained all local configuration and
customizations from a ``localrc`` file. In Oct 2013 the
``local.conf`` configuration method was introduced (in `review 46768
<https://review.opendev.org/#/c/46768/>`__) to simplify this
process.
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
Configuration Notes
===================
.. contents::
:local:
Remove shocco docs and other cleanups This is a fairly opinionated change to do some spring cleaning on the documentation. The current output of shocco as rendered at [1] is completely broken. I can not see that it is worth us maintaining this. Honestly, the github page does a better job at showing the scripts with a bit of formatting. The "changes" page is similarly useless today. cgit or github show allow browsing of changes in the repo better. Both are removed along with support scripts. When you currently hit the first page, it gives no clue as to what DevStack actually is. Add a paragraph explaining that, and link to the cgit for easy source browsing. stackrc.rst is not necessary; the stuff about database backends is already discussed in configuration.rst; move the things about service repos into a section of configuration.rst. The discussion in openrc.rst is moved into the configuration.rst file. localrc.conf.rst was just a paragraph pointing back to configuration.rst; this is removed. The variables described in exercise.rst are moved into a separate section of configuration.rst [1] http://docs.openstack.org/developer/devstack/#scripts Change-Id: Ie7f4b265368f1d10a8908d75e11d625b2cc39e7c
2016年04月08日 09:40:56 +10:00
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.
::
Remove shocco docs and other cleanups This is a fairly opinionated change to do some spring cleaning on the documentation. The current output of shocco as rendered at [1] is completely broken. I can not see that it is worth us maintaining this. Honestly, the github page does a better job at showing the scripts with a bit of formatting. The "changes" page is similarly useless today. cgit or github show allow browsing of changes in the repo better. Both are removed along with support scripts. When you currently hit the first page, it gives no clue as to what DevStack actually is. Add a paragraph explaining that, and link to the cgit for easy source browsing. stackrc.rst is not necessary; the stuff about database backends is already discussed in configuration.rst; move the things about service repos into a section of configuration.rst. The discussion in openrc.rst is moved into the configuration.rst file. localrc.conf.rst was just a paragraph pointing back to configuration.rst; this is removed. The variables described in exercise.rst are moved into a separate section of configuration.rst [1] http://docs.openstack.org/developer/devstack/#scripts Change-Id: Ie7f4b265368f1d10a8908d75e11d625b2cc39e7c
2016年04月08日 09:40:56 +10:00
NOVA_REPO=$GIT_BASE/openstack/nova.git
NOVA_BRANCH=master
Remove shocco docs and other cleanups This is a fairly opinionated change to do some spring cleaning on the documentation. The current output of shocco as rendered at [1] is completely broken. I can not see that it is worth us maintaining this. Honestly, the github page does a better job at showing the scripts with a bit of formatting. The "changes" page is similarly useless today. cgit or github show allow browsing of changes in the repo better. Both are removed along with support scripts. When you currently hit the first page, it gives no clue as to what DevStack actually is. Add a paragraph explaining that, and link to the cgit for easy source browsing. stackrc.rst is not necessary; the stuff about database backends is already discussed in configuration.rst; move the things about service repos into a section of configuration.rst. The discussion in openrc.rst is moved into the configuration.rst file. localrc.conf.rst was just a paragraph pointing back to configuration.rst; this is removed. The variables described in exercise.rst are moved into a separate section of configuration.rst [1] http://docs.openstack.org/developer/devstack/#scripts Change-Id: Ie7f4b265368f1d10a8908d75e11d625b2cc39e7c
2016年04月08日 09:40:56 +10:00
To pull a branch directly from Gerrit, get the repo and branch from
the Gerrit review page::
Remove shocco docs and other cleanups This is a fairly opinionated change to do some spring cleaning on the documentation. The current output of shocco as rendered at [1] is completely broken. I can not see that it is worth us maintaining this. Honestly, the github page does a better job at showing the scripts with a bit of formatting. The "changes" page is similarly useless today. cgit or github show allow browsing of changes in the repo better. Both are removed along with support scripts. When you currently hit the first page, it gives no clue as to what DevStack actually is. Add a paragraph explaining that, and link to the cgit for easy source browsing. stackrc.rst is not necessary; the stuff about database backends is already discussed in configuration.rst; move the things about service repos into a section of configuration.rst. The discussion in openrc.rst is moved into the configuration.rst file. localrc.conf.rst was just a paragraph pointing back to configuration.rst; this is removed. The variables described in exercise.rst are moved into a separate section of configuration.rst [1] http://docs.openstack.org/developer/devstack/#scripts Change-Id: Ie7f4b265368f1d10a8908d75e11d625b2cc39e7c
2016年04月08日 09:40:56 +10:00
git fetch https://review.opendev.org/openstack/nova \
refs/changes/50/5050/1 && git checkout FETCH_HEAD
Remove shocco docs and other cleanups This is a fairly opinionated change to do some spring cleaning on the documentation. The current output of shocco as rendered at [1] is completely broken. I can not see that it is worth us maintaining this. Honestly, the github page does a better job at showing the scripts with a bit of formatting. The "changes" page is similarly useless today. cgit or github show allow browsing of changes in the repo better. Both are removed along with support scripts. When you currently hit the first page, it gives no clue as to what DevStack actually is. Add a paragraph explaining that, and link to the cgit for easy source browsing. stackrc.rst is not necessary; the stuff about database backends is already discussed in configuration.rst; move the things about service repos into a section of configuration.rst. The discussion in openrc.rst is moved into the configuration.rst file. localrc.conf.rst was just a paragraph pointing back to configuration.rst; this is removed. The variables described in exercise.rst are moved into a separate section of configuration.rst [1] http://docs.openstack.org/developer/devstack/#scripts Change-Id: Ie7f4b265368f1d10a8908d75e11d625b2cc39e7c
2016年04月08日 09:40:56 +10:00
The repo is the stanza following ``fetch`` and the branch is the
stanza following that::
Remove shocco docs and other cleanups This is a fairly opinionated change to do some spring cleaning on the documentation. The current output of shocco as rendered at [1] is completely broken. I can not see that it is worth us maintaining this. Honestly, the github page does a better job at showing the scripts with a bit of formatting. The "changes" page is similarly useless today. cgit or github show allow browsing of changes in the repo better. Both are removed along with support scripts. When you currently hit the first page, it gives no clue as to what DevStack actually is. Add a paragraph explaining that, and link to the cgit for easy source browsing. stackrc.rst is not necessary; the stuff about database backends is already discussed in configuration.rst; move the things about service repos into a section of configuration.rst. The discussion in openrc.rst is moved into the configuration.rst file. localrc.conf.rst was just a paragraph pointing back to configuration.rst; this is removed. The variables described in exercise.rst are moved into a separate section of configuration.rst [1] http://docs.openstack.org/developer/devstack/#scripts Change-Id: Ie7f4b265368f1d10a8908d75e11d625b2cc39e7c
2016年04月08日 09:40:56 +10:00
NOVA_REPO=https://review.opendev.org/openstack/nova
NOVA_BRANCH=refs/changes/50/5050/1
Remove shocco docs and other cleanups This is a fairly opinionated change to do some spring cleaning on the documentation. The current output of shocco as rendered at [1] is completely broken. I can not see that it is worth us maintaining this. Honestly, the github page does a better job at showing the scripts with a bit of formatting. The "changes" page is similarly useless today. cgit or github show allow browsing of changes in the repo better. Both are removed along with support scripts. When you currently hit the first page, it gives no clue as to what DevStack actually is. Add a paragraph explaining that, and link to the cgit for easy source browsing. stackrc.rst is not necessary; the stuff about database backends is already discussed in configuration.rst; move the things about service repos into a section of configuration.rst. The discussion in openrc.rst is moved into the configuration.rst file. localrc.conf.rst was just a paragraph pointing back to configuration.rst; this is removed. The variables described in exercise.rst are moved into a separate section of configuration.rst [1] http://docs.openstack.org/developer/devstack/#scripts Change-Id: Ie7f4b265368f1d10a8908d75e11d625b2cc39e7c
2016年04月08日 09:40:56 +10:00
Installation Directory
----------------------
The DevStack install directory is set by the ``DEST`` variable. By
default it is ``/opt/stack``.
By setting it early in the ``localrc`` section you can reference it in
later variables. It can be useful to set it even though it is not
changed from the default value.
::
DEST=/opt/stack
Logging
-------
.. _enable_logging:
Enable Logging
~~~~~~~~~~~~~~
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.
::
LOGDAYS=2
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
~~~~~~~~~~~~~~~~~~~~~~~~~~
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`.
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
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
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
Database Backend
----------------
Revert "Remove deprecated PostgreSQL database driver" This reverts commit 168ca7f0a474f1207ee01dab0ca2e70f34783e9c. Removing postgresql support from devstack was unnecessary since it's not broken and not causing maintenance issues as far as I know. The commit being reverted said that pg support was deprecated in Pike but nothing in the docs or commit message refer to official deprecation of postgres support in devstack or openstack in general. Not to mention that there are still postgres-based jobs that will no longer work *and* the notification to the mailing list about doing this happened *after* it was already done [1] leaving stakeholders with no time to reply. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010196.html Change-Id: Ie7036d37d79e6aba462b7c97f917e2e7aed108f9
2019年10月17日 19:34:05 +00:00
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::
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
disable_service mysql
Revert "Remove deprecated PostgreSQL database driver" This reverts commit 168ca7f0a474f1207ee01dab0ca2e70f34783e9c. Removing postgresql support from devstack was unnecessary since it's not broken and not causing maintenance issues as far as I know. The commit being reverted said that pg support was deprecated in Pike but nothing in the docs or commit message refer to official deprecation of postgres support in devstack or openstack in general. Not to mention that there are still postgres-based jobs that will no longer work *and* the notification to the mailing list about doing this happened *after* it was already done [1] leaving stakeholders with no time to reply. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010196.html Change-Id: Ie7036d37d79e6aba462b7c97f917e2e7aed108f9
2019年10月17日 19:34:05 +00:00
enable_service postgresql
``mysql`` is the default database.
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
RPC Backend
-----------
Revert "Remove deprecated PostgreSQL database driver" This reverts commit 168ca7f0a474f1207ee01dab0ca2e70f34783e9c. Removing postgresql support from devstack was unnecessary since it's not broken and not causing maintenance issues as far as I know. The commit being reverted said that pg support was deprecated in Pike but nothing in the docs or commit message refer to official deprecation of postgres support in devstack or openstack in general. Not to mention that there are still postgres-based jobs that will no longer work *and* the notification to the mailing list about doing this happened *after* it was already done [1] leaving stakeholders with no time to reply. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010196.html Change-Id: Ie7036d37d79e6aba462b7c97f917e2e7aed108f9
2019年10月17日 19:34:05 +00:00
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``::
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
disable_service rabbit
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
Revert "Remove deprecated PostgreSQL database driver" This reverts commit 168ca7f0a474f1207ee01dab0ca2e70f34783e9c. Removing postgresql support from devstack was unnecessary since it's not broken and not causing maintenance issues as far as I know. The commit being reverted said that pg support was deprecated in Pike but nothing in the docs or commit message refer to official deprecation of postgres support in devstack or openstack in general. Not to mention that there are still postgres-based jobs that will no longer work *and* the notification to the mailing list about doing this happened *after* it was already done [1] leaving stakeholders with no time to reply. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010196.html Change-Id: Ie7036d37d79e6aba462b7c97f917e2e7aed108f9
2019年10月17日 19:34:05 +00:00
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
Apache Frontend
---------------
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)::
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
KEYSTONE_USE_MOD_WSGI="True"
Example (Nova)::
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
NOVA_USE_MOD_WSGI="True"
Example (Swift)::
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
SWIFT_USE_MOD_WSGI="True"
Example (Heat)::
HEAT_USE_MOD_WSGI="True"
Example (Cinder)::
CINDER_USE_MOD_WSGI="True"
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
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"
A clean install every time
--------------------------
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``.
::
RECLONE=yes
Upgrade packages installed by pip
---------------------------------
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
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.
::
DOWNLOAD_DEFAULT_IMAGES=False
IMAGE_URLS="http://foo.bar.com/image.qcow,"
IMAGE_URLS+="http://foo.bar.com/image2.qcow"
Instance Type
-------------
``DEFAULT_INSTANCE_TYPE`` can be used to configure the default instance
type. When this parameter is not specified, Devstack creates additional
micro & nano flavors for really small instances to run Tempest tests.
For guests with larger memory requirements, ``DEFAULT_INSTANCE_TYPE``
should be specified in the configuration file so Tempest selects the
default flavors instead.
KVM on Power with QEMU 2.4 requires 512 MB to load the firmware -
`QEMU 2.4 - PowerPC <https://wiki.qemu.org/ChangeLog/2.4>`__ so users
running instances on ppc64/ppc64le can choose one of the default
created flavors as follows:
::
DEFAULT_INSTANCE_TYPE=m1.tiny
Add IPv6 support for tenant data network Define IP_VERSION with one of the three values 4, 6, or 4+6 in your localrc to indicate if you intend to run your tenant data network as either IPv4, IPv6, or dual stack respectively. Default value is 4. If your IP_VERSION is set to 6 or 4+6, then the following variables should be defined in your localrc: - FIXED_RANGE_V6: The IPv6 prefix for your tenant network - IPV6_PRIVATE_NETWORK_GATEWAY: The gateway IP with the same prefix - IPV6_RA_MODE (with default as slaac) - IPV6_ADDRESS_MODE (with default as slaac) If you're going to use IPV6_RA_MODE/IPV6_ADDRESS_MODE settings other than the defaults then you should make sure your VM image has dhcpv6 client enabled at bootup, otherwise you'll need to run it manually after the VM is booted. It's recommended to run the latest version of dnsmasq 2.68. If you intend to enable internet access in your VM, make sure your network node has IPv6 internet access, and the IPv6 prefix for your tenant network is a GUA and routable. Implements: blueprint ipv6-support Change-Id: I848abf18e00e2a869697c5ef6366bc567dde448a Co-Authored-By: John Davidge <jodavidg@cisco.com>
2014年06月30日 09:55:11 -04:00
IP Version
Add IPv6 support to devstack infrastructure By default, most Openstack services are bound to 0.0.0.0 and service endpoints are registered as IPv4 addresses. With this change we introduce two new variables to control this behavior: SERVICE_IP_VERSION - can either be "4" or "6". When set to "4" (default if not set) devstack will operate as today - most services will open listen sockets on 0.0.0.0 and service endpoints will be registered using HOST_IP as the address. When set to "6" devstack services will open listen sockets on :: and service endpoints will be registered using HOST_IPV6 as the address. There is no support for "4+6", more work is required for that. HOST_IPV6 - if SERVICE_IP_VERSION=6 this must be an IPv6 address configured on the system. Some existing services, like the Openvswitch agent, will continue to use IPv4 addresses for things like tunnel endpoints. This is a current restriction in the code and can be updated at a later time. This change is just a first step to supporting IPv6-only control and data planes in devstack. This change is also partly based on two previous patches, https://review.openstack.org/#/c/140519/ and https://review.openstack.org/#/c/176898/ Change-Id: I5c0b775490ce54ab104fd5e89b20fb700212ae74 Co-Authored-By: Sean Collins <sean@coreitpro.com> Co-Authored-By: Baodong Li <baoli@cisco.com> Co-Authored-By: Sridhar Gaddam <sridhar.gaddam@enovance.com> Co-Authored-By: Adam Kacmarsky <adam.kacmarsky@hp.com> Co-Authored-By: Jeremy Alvis <jeremy.alvis@hp.com>
2015年06月16日 13:14:31 -04:00
----------
``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.
Add IPv6 support for tenant data network Define IP_VERSION with one of the three values 4, 6, or 4+6 in your localrc to indicate if you intend to run your tenant data network as either IPv4, IPv6, or dual stack respectively. Default value is 4. If your IP_VERSION is set to 6 or 4+6, then the following variables should be defined in your localrc: - FIXED_RANGE_V6: The IPv6 prefix for your tenant network - IPV6_PRIVATE_NETWORK_GATEWAY: The gateway IP with the same prefix - IPV6_RA_MODE (with default as slaac) - IPV6_ADDRESS_MODE (with default as slaac) If you're going to use IPV6_RA_MODE/IPV6_ADDRESS_MODE settings other than the defaults then you should make sure your VM image has dhcpv6 client enabled at bootup, otherwise you'll need to run it manually after the VM is booted. It's recommended to run the latest version of dnsmasq 2.68. If you intend to enable internet access in your VM, make sure your network node has IPv6 internet access, and the IPv6 prefix for your tenant network is a GUA and routable. Implements: blueprint ipv6-support Change-Id: I848abf18e00e2a869697c5ef6366bc567dde448a Co-Authored-By: John Davidge <jodavidg@cisco.com>
2014年06月30日 09:55:11 -04:00
::
Add IPv6 support for tenant data network Define IP_VERSION with one of the three values 4, 6, or 4+6 in your localrc to indicate if you intend to run your tenant data network as either IPv4, IPv6, or dual stack respectively. Default value is 4. If your IP_VERSION is set to 6 or 4+6, then the following variables should be defined in your localrc: - FIXED_RANGE_V6: The IPv6 prefix for your tenant network - IPV6_PRIVATE_NETWORK_GATEWAY: The gateway IP with the same prefix - IPV6_RA_MODE (with default as slaac) - IPV6_ADDRESS_MODE (with default as slaac) If you're going to use IPV6_RA_MODE/IPV6_ADDRESS_MODE settings other than the defaults then you should make sure your VM image has dhcpv6 client enabled at bootup, otherwise you'll need to run it manually after the VM is booted. It's recommended to run the latest version of dnsmasq 2.68. If you intend to enable internet access in your VM, make sure your network node has IPv6 internet access, and the IPv6 prefix for your tenant network is a GUA and routable. Implements: blueprint ipv6-support Change-Id: I848abf18e00e2a869697c5ef6366bc567dde448a Co-Authored-By: John Davidge <jodavidg@cisco.com>
2014年06月30日 09:55:11 -04:00
IP_VERSION=4+6
Add IPv6 support for tenant data network Define IP_VERSION with one of the three values 4, 6, or 4+6 in your localrc to indicate if you intend to run your tenant data network as either IPv4, IPv6, or dual stack respectively. Default value is 4. If your IP_VERSION is set to 6 or 4+6, then the following variables should be defined in your localrc: - FIXED_RANGE_V6: The IPv6 prefix for your tenant network - IPV6_PRIVATE_NETWORK_GATEWAY: The gateway IP with the same prefix - IPV6_RA_MODE (with default as slaac) - IPV6_ADDRESS_MODE (with default as slaac) If you're going to use IPV6_RA_MODE/IPV6_ADDRESS_MODE settings other than the defaults then you should make sure your VM image has dhcpv6 client enabled at bootup, otherwise you'll need to run it manually after the VM is booted. It's recommended to run the latest version of dnsmasq 2.68. If you intend to enable internet access in your VM, make sure your network node has IPv6 internet access, and the IPv6 prefix for your tenant network is a GUA and routable. Implements: blueprint ipv6-support Change-Id: I848abf18e00e2a869697c5ef6366bc567dde448a Co-Authored-By: John Davidge <jodavidg@cisco.com>
2014年06月30日 09:55:11 -04:00
The following optional variables can be used to alter the default IPv6
behavior:
Add IPv6 support for tenant data network Define IP_VERSION with one of the three values 4, 6, or 4+6 in your localrc to indicate if you intend to run your tenant data network as either IPv4, IPv6, or dual stack respectively. Default value is 4. If your IP_VERSION is set to 6 or 4+6, then the following variables should be defined in your localrc: - FIXED_RANGE_V6: The IPv6 prefix for your tenant network - IPV6_PRIVATE_NETWORK_GATEWAY: The gateway IP with the same prefix - IPV6_RA_MODE (with default as slaac) - IPV6_ADDRESS_MODE (with default as slaac) If you're going to use IPV6_RA_MODE/IPV6_ADDRESS_MODE settings other than the defaults then you should make sure your VM image has dhcpv6 client enabled at bootup, otherwise you'll need to run it manually after the VM is booted. It's recommended to run the latest version of dnsmasq 2.68. If you intend to enable internet access in your VM, make sure your network node has IPv6 internet access, and the IPv6 prefix for your tenant network is a GUA and routable. Implements: blueprint ipv6-support Change-Id: I848abf18e00e2a869697c5ef6366bc567dde448a Co-Authored-By: John Davidge <jodavidg@cisco.com>
2014年06月30日 09:55:11 -04:00
::
Add IPv6 support for tenant data network Define IP_VERSION with one of the three values 4, 6, or 4+6 in your localrc to indicate if you intend to run your tenant data network as either IPv4, IPv6, or dual stack respectively. Default value is 4. If your IP_VERSION is set to 6 or 4+6, then the following variables should be defined in your localrc: - FIXED_RANGE_V6: The IPv6 prefix for your tenant network - IPV6_PRIVATE_NETWORK_GATEWAY: The gateway IP with the same prefix - IPV6_RA_MODE (with default as slaac) - IPV6_ADDRESS_MODE (with default as slaac) If you're going to use IPV6_RA_MODE/IPV6_ADDRESS_MODE settings other than the defaults then you should make sure your VM image has dhcpv6 client enabled at bootup, otherwise you'll need to run it manually after the VM is booted. It's recommended to run the latest version of dnsmasq 2.68. If you intend to enable internet access in your VM, make sure your network node has IPv6 internet access, and the IPv6 prefix for your tenant network is a GUA and routable. Implements: blueprint ipv6-support Change-Id: I848abf18e00e2a869697c5ef6366bc567dde448a Co-Authored-By: John Davidge <jodavidg@cisco.com>
2014年06月30日 09:55:11 -04:00
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
Add IPv6 support for tenant data network Define IP_VERSION with one of the three values 4, 6, or 4+6 in your localrc to indicate if you intend to run your tenant data network as either IPv4, IPv6, or dual stack respectively. Default value is 4. If your IP_VERSION is set to 6 or 4+6, then the following variables should be defined in your localrc: - FIXED_RANGE_V6: The IPv6 prefix for your tenant network - IPV6_PRIVATE_NETWORK_GATEWAY: The gateway IP with the same prefix - IPV6_RA_MODE (with default as slaac) - IPV6_ADDRESS_MODE (with default as slaac) If you're going to use IPV6_RA_MODE/IPV6_ADDRESS_MODE settings other than the defaults then you should make sure your VM image has dhcpv6 client enabled at bootup, otherwise you'll need to run it manually after the VM is booted. It's recommended to run the latest version of dnsmasq 2.68. If you intend to enable internet access in your VM, make sure your network node has IPv6 internet access, and the IPv6 prefix for your tenant network is a GUA and routable. Implements: blueprint ipv6-support Change-Id: I848abf18e00e2a869697c5ef6366bc567dde448a Co-Authored-By: John Davidge <jodavidg@cisco.com>
2014年06月30日 09:55:11 -04:00
Derive IP ranges from new ADDRS_SAFE_TO_USE vars The switch to using subnetpools caused quite a bit of confusion because it didn't respect the value of FIXED_RANGE. This caused conflicts in the gate with it's default IPv4 value of 10.0.0.0/8. This patch does a few things to address the issue: * It introduces the IPV4_ADDRS_SAFE_TO_USE and IPV6_ADDRS_SAFE_TO_USE values and adjusts all of the FIXED_RANGE and SUBNETPOOL_PREFIX values to dervive from them by default. * This addresses the concern that was raised about implying that SUBNETPOOL_PREFIX and FIXED_RANGE are equivalent when setting SUBNETPOOL_PREFIX=FIXED_RANGE by default. Now we have a new value for the operator specify a chunk of addresses that are safe to use for private networks without implementation implications. * Backwards compatibility is maintained by alloing users to override override all of these values. * The default for IPV4_ADDRS_SAFE_TO_USE uses /22 instead of /24 * Because we want to be able to use subnetpools for auto allocated topologies and we want to be able to have a large chunk of instances on each network, we needed a little more breathing room in the default v4 network size. * SUBNET_POOL_SIZE_V4 default is changed from 24 to 26 * In conjuction with this change and the one above, the default subnetpool will support up to 16 64-address allocations. * This should be enough to cover any regular gate scenarios. * If someone wants a bigger/smaller subnet, they can ask for that in the API request, change this value themselves, or use a different network entirely. * FIXED_RANGE_V6 defaults to a max prefix of /64 from IPV6_ADDRS_SAFE_TO_USE * This avoids the private subnet in the non-subnetpool case from being larger than /64 to avoid issues identified in rfc 7421. * Users can still explicitly set this value to whatever they want. This 'max' behavior is only for the default. * This allows IPV6_ADDRS_SAFE_TO_USE to default to a /56, which leaves tons of room for v6 subnetpools. Closes-Bug: #1629133 Change-Id: I7b32804d47bec743c0b13e434e6a7958728896ea
2016年11月15日 17:26:05 -08:00
*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.
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.
When set to ``6`` devstack services will open listen sockets on ``::``
and service endpoints will be registered using ``HOST_IPV6`` as the
address.
The default value for this setting is ``4``. Dual-mode support, for
example ``4+6`` is not currently supported. ``HOST_IPV6`` can
optionally be used to alter the default IPv6 address::
Add IPv6 support to devstack infrastructure By default, most Openstack services are bound to 0.0.0.0 and service endpoints are registered as IPv4 addresses. With this change we introduce two new variables to control this behavior: SERVICE_IP_VERSION - can either be "4" or "6". When set to "4" (default if not set) devstack will operate as today - most services will open listen sockets on 0.0.0.0 and service endpoints will be registered using HOST_IP as the address. When set to "6" devstack services will open listen sockets on :: and service endpoints will be registered using HOST_IPV6 as the address. There is no support for "4+6", more work is required for that. HOST_IPV6 - if SERVICE_IP_VERSION=6 this must be an IPv6 address configured on the system. Some existing services, like the Openvswitch agent, will continue to use IPv4 addresses for things like tunnel endpoints. This is a current restriction in the code and can be updated at a later time. This change is just a first step to supporting IPv6-only control and data planes in devstack. This change is also partly based on two previous patches, https://review.openstack.org/#/c/140519/ and https://review.openstack.org/#/c/176898/ Change-Id: I5c0b775490ce54ab104fd5e89b20fb700212ae74 Co-Authored-By: Sean Collins <sean@coreitpro.com> Co-Authored-By: Baodong Li <baoli@cisco.com> Co-Authored-By: Sridhar Gaddam <sridhar.gaddam@enovance.com> Co-Authored-By: Adam Kacmarsky <adam.kacmarsky@hp.com> Co-Authored-By: Jeremy Alvis <jeremy.alvis@hp.com>
2015年06月16日 13:14:31 -04:00
HOST_IPV6=${some_local_ipv6_address}
Add IPv6 support for tenant data network Define IP_VERSION with one of the three values 4, 6, or 4+6 in your localrc to indicate if you intend to run your tenant data network as either IPv4, IPv6, or dual stack respectively. Default value is 4. If your IP_VERSION is set to 6 or 4+6, then the following variables should be defined in your localrc: - FIXED_RANGE_V6: The IPv6 prefix for your tenant network - IPV6_PRIVATE_NETWORK_GATEWAY: The gateway IP with the same prefix - IPV6_RA_MODE (with default as slaac) - IPV6_ADDRESS_MODE (with default as slaac) If you're going to use IPV6_RA_MODE/IPV6_ADDRESS_MODE settings other than the defaults then you should make sure your VM image has dhcpv6 client enabled at bootup, otherwise you'll need to run it manually after the VM is booted. It's recommended to run the latest version of dnsmasq 2.68. If you intend to enable internet access in your VM, make sure your network node has IPv6 internet access, and the IPv6 prefix for your tenant network is a GUA and routable. Implements: blueprint ipv6-support Change-Id: I848abf18e00e2a869697c5ef6366bc567dde448a Co-Authored-By: John Davidge <jodavidg@cisco.com>
2014年06月30日 09:55:11 -04:00
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
Multi-node setup
~~~~~~~~~~~~~~~~
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
See the :doc:`multi-node lab guide<guides/multinode-lab>`
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
Projects
--------
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
Neutron
~~~~~~~
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
See the :doc:`neutron configuration guide<guides/neutron>` for
details on configuration of Neutron
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
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.
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
If you would like to enable Swift you can add this to your ``localrc``
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
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:
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
::
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).
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
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"
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
Swift S3
++++++++
If you are enabling ``s3api`` in ``ENABLED_SERVICES`` DevStack will
install the s3api middleware emulation. Swift will be configured to
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
act as a S3 endpoint for Keystone so effectively replacing the
``nova-objectstore``.
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
Only Swift proxy server is launched in the systemd system all other
services are started in background and managed by ``swift-init`` tool.
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
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
Cinder
~~~~~~
The logical volume group used to hold the Cinder-managed volumes is
set by ``VOLUME_GROUP_NAME``, the logical volume name prefix is set with
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
``VOLUME_NAME_PREFIX`` and the size of the volume backing file is set
with ``VOLUME_BACKING_FILE_SIZE``.
::
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
VOLUME_GROUP_NAME="stack-volumes"
VOLUME_NAME_PREFIX="volume-"
VOLUME_BACKING_FILE_SIZE=24G
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
When running highly concurrent tests, the default per-project quotas
for volumes, backups, or snapshots may be too small. These can be
adjusted by setting ``CINDER_QUOTA_VOLUMES``, ``CINDER_QUOTA_BACKUPS``,
or ``CINDER_QUOTA_SNAPSHOTS`` to the desired value. (The default for
each is 10.)
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
Keystone
~~~~~~~~
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:
::
Move configuration notes into configuration guide We have configuration information split between the README.md and configuration documentation. A lot of it is duplicated and it shows little organisation. This clears the README.md of detailed configuration options and consolidates it into the existing configuration guide. When someone first hits the README they don't need details on changing the RPC back-end; but more importantly this indicates clearly where we should be adding or clarifying details. Firstly, the detailed overview of local.conf is removed; it was duplicated in the configuration guide. This is left as a first-level section of that guide. The configuration notes are divided into generic devstack things (logging, database-backend, etc) and then the rest of the notes on various projects' configuration options have been moved into a dedicated sub-section "Projects". Each project gets its own sub-sub-section. Duplicated swift guides is consolidated into the single "Swift section". The neutron and multi-node nodes, which were all duplicated in their more specific dedicated guides are removed and replaced with links to those. Other sections are moved directly. Change-Id: Ib0bac56d82be870fe99c47c53fda674d8668b968
2015年08月10日 13:39:17 +10:00
disable_service horizon
KEYSTONE_SERVICE_HOST=<KEYSTONE_IP_ADDRESS_FROM_REGION_ONE>
REGION_NAME=RegionTwo
Fix DevStack failure in multi-region setting In stack.sh, REGION_NAME is used to set environment variable OS_REGION_NAME before using OpenStack client to configure accounts for services. OpenStack client will try to find Keystone endpoint in REGION_NAME to send the requests. However, in the case of deploying multiple DevStack instances in different regions with shared Keystone, Keystone is only running in one the of region. When installing DevStack for the region that does not host Keystone, OpenStack client will fail to find the Keystone endpoint and thus DevStack fails to start. This patch fixes this bug by introducing KEYSTONE_REGION_NAME for user to specify which region Keystone is running in. Document of multi-region setup is also updated. Change-Id: I3e82c7ff69326d4171623299ffecea103d40c80d Closes-Bug: #1540802
2016年04月07日 18:36:46 +08:00
KEYSTONE_REGION_NAME=RegionOne
In the devstack for RegionOne, we set REGION_NAME as RegionOne, so region of
the services started in this devstack are registered as RegionOne. In devstack
for RegionTwo, similarly, we set REGION_NAME as RegionTwo since we want
services started in this devstack to be registered in RegionTwo. But Keystone
service is started and registered in RegionOne, not RegionTwo, so we use
KEYSTONE_REGION_NAME to specify the region of Keystone service.
KEYSTONE_REGION_NAME has a default value the same as REGION_NAME thus we omit
it in the configuration of RegionOne.
Glance
++++++
The default image size quota of 1GiB may be too small if larger images
are to be used. Change the default at setup time with:
::
GLANCE_LIMIT_IMAGE_SIZE_TOTAL=5000
or at runtime via:
::
openstack --os-cloud devstack-system-admin registered limit update \
--service glance --default-limit 5000 --region RegionOne image_size_total
.. _arch-configuration:
Architectures
-------------
The upstream CI runs exclusively on nodes with x86 architectures, but
OpenStack supports even more architectures. Some of them need to configure
Devstack in a certain way.
KVM on s390x (IBM z Systems)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KVM on s390x (IBM z Systems) is supported since the *Kilo* release. For
an all-in-one setup, these minimal settings in the ``local.conf`` file
are needed::
[[local|localrc]]
ADMIN_PASSWORD=secret
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
DOWNLOAD_DEFAULT_IMAGES=False
IMAGE_URLS="https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-s390x-disk1.img"
# Provide a custom etcd3 binary download URL and ints sha256.
# The binary must be located under '/<etcd version>/etcd-<etcd-version>-linux-s390x.tar.gz'
# on this URL.
# Build instructions for etcd3: https://github.com/linux-on-ibm-z/docs/wiki/Building-etcd
ETCD_DOWNLOAD_URL=<your-etcd-download-url>
ETCD_SHA256=<your-etcd3-sha256>
enable_service n-sproxy
disable_service n-novnc
[[post-config|$NOVA_CONF]]
[serial_console]
base_url=ws://$HOST_IP:6083/ # optional
Reasoning:
* The default image of Devstack is x86 only, so we deactivate the download
with ``DOWNLOAD_DEFAULT_IMAGES``. The referenced guest image
in the code above (``IMAGE_URLS``) serves as an example. The list of
possible s390x guest images is not limited to that.
* This platform doesn't support a graphical console like VNC or SPICE.
The technical reason is the missing framebuffer on the platform. This
means we rely on the substitute feature *serial console* which needs the
proxy service ``n-sproxy``. We also disable VNC's proxy ``n-novnc`` for
that reason . The configuration in the ``post-config`` section is only
needed if you want to use the *serial console* outside of the all-in-one
setup.
* A link to an etcd3 binary and its sha256 needs to be provided as the
binary for s390x is not hosted on github like it is for other
architectures. For more details see
https://bugs.launchpad.net/devstack/+bug/1693192. Etcd3 can easily be
built along https://github.com/linux-on-ibm-z/docs/wiki/Building-etcd.
.. note:: To run *Tempest* against this *Devstack* all-in-one, you'll need
to use a guest image which is smaller than 1GB when uncompressed.
The example image from above is bigger than that!