We should be using $VOLUME_GROUP_NAME instead since Icehouse.
$VOLUME_GROUP_NAME has been introduced in
I93b8ef32832269d730c76a6dc24ddb4f20c6d9df and $VOLUME_GROUP is nowadays
only use as a fallback to $VOLUME_GROUP_NAME.
As a code comment in lib/lvm says it we kept the $VOLUME_GROUP around as
"for compatibility with icehouse-generation Grenade". Icehouse is long
gone so now seems a good time to remove any usage of $VOLUME_GROUP.
Change-Id: Id3051b5a196c45266c39fde4f08401aaacf0f6bd
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
The prior art on other options in the same document seemed to be
calling out the default in a pre-formatted block after describing the
possible values.
I believe the default value for the option was first changed [1], then
the docs were fixed [2], then the information was unintentionally
dropped from the docs [3].
1. Related-Change: If0e0b818355e4cb1338f7fa72af5e81e24361574
2. Related-Change: Ib6603b4f6ea0b4079f9a4ea46e723ecbb2ea371d
3. Related-Change: Iddd27cb54f1d9f062b9c47ff9ad6a2bef3650d6b
Change-Id: I662403db3b08a351a680587440ad1f15a6f8ee5d
The local.conf docs talk about phases which don't exist for config
file processing, which makes it more confusing then it needs to be.
Change-Id: If7f9255eab0535c3d57a2fd5f1bc18ba4d0801aa
For client debugging that invokes multiple libs it can be useful
to have all libs directly in git and not listing all of them
in LIBS_FROM_GIT.
TrivialFix
Change-Id: Ie631cc4045231ebbe8177d2d113e47e4bf83f61c
If the variable SWIFT_STORAGE_IPS contains a space-separated list of
IPs, we can use this to create consistent rings across all proxy and
storage nodes.
Change-Id: If9307196dc7e74e4a842c95503958ae2d7f7acc7
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
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
Apparently this is intentional as a joke on devstack leaking
passwords, but the dual meaning of the word confuses people. Let's
change it before we get yet another review fixing it.
Change-Id: I3bee03612f6ea197362aab04a37f81043f77f235
This is just another code path for little benefit in devstack which is
going to rot out. We should be opinionated here and only support the
dynamic catalog.
Change-Id: I4e5c7e86aefe72fc21c77d423033e9b169318fec
there are a few lingering instances of SERVICE_TOKEN in the docs
and some of the scripts in tools.
Change-Id: I9d2147eea6639db1f4ea15a259c147eecfc339ff
* ReST doesn't allow monospace in italic sections.
bash$ grep -R \`\` doc/build/html/ --include "*.html"
* The code-block section "::" needed an empty line before the code,
otherwise it gets shown in the HTML output.
bash$ egrep -R "<dt>::" doc/build/html/ --include "*.html"
* Monospaced font incorrectly marked with a single back tick
bash$ egrep -nR '\w`(\s|[\.,;:])' doc/source/ --include "*.rst"
Change-Id: I66c3f685f33851c3f3f0f859996037fc24930246
As files/keystone_data.sh has been removed in the commit
https://review.openstack.org/#/c/79366/, we should remove some
related documations and comments.
Change-Id: I7802d0052fa28d8debb7f361d36a4f108869554c
Add templates for running Heat API services via
apache mod_wsgi. Also add appropriate functions to
lib/heat for configuring Heat.
Change-Id: I1bdd678c44ddfa616a9db7db85ff6f490ff08947
Guests with large memory requirements can use default flavors, so
removing the special flavor for ppc64 since new qemu requires more
memory - http://wiki.qemu.org/ChangeLog/2.4 - PowerPC.
Users should set DEFAULT_INSTANCE_TYPE to one of the default
flavors available in local.conf, as m1.tiny.
DocImpact
Change-Id: I0fd275dc7342cc2daa83e9a2bd79d30e7defa3e4
This change adds apache templates for Cinder API services.
Also add possibility to switch between the old and new ways
to setup Cinder API.
Related Cinder blueprint:
https://blueprints.launchpad.net/cinder/+spec/non-eventlet-wsgi-app
Change-Id: Icfad40ee6998296727a95613199e5c2d87bd0a45
Depends-On: Ifbab059001d1567b1f7b394c0411a9ca4629f846
Co-Authored-By: Ivan Kolodyazhny <e0ne@e0ne.info>
IMAGE_URLS could be set both in localrc with customization or stackrc by
default. By setting DOWNLOAD_DEFAULT_IMAGES, user could choose to add
default images to IMAGE_URLS or overwrite them.
As uploading duplicate images will cause a "409 Conflict" error, a
duplicate detection will expose it earlier.
Care needs to be taken that you don't end up with a duplicate image, so
clean up Xen's README.
Depends-On: I6fbae12f950a03afab39f341132746d3db9f788c
Change-Id: I3ca4e576aa3fb8992c08ca44900a8c53dd4b4163
Closes-Bug: #1473432
We bury the lead with all the historical notes about localrc; just
talk about what is important to somebody setting up a current
devstack, which is local.conf.
There are already inline examples of config-variables, etc. Remove
them, but add a small overview example for logging in its place.
Change-Id: I466252ffba66ef4ea180c9355f715a19eb4f8017
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
It was shown that the local.conf is at root devstack directory, but
it is at devstack/samples directory. So the path is updated.
1.) Copy the file into root Devstack directory.
Change-Id: I6ff8a404a3664c892bb458023c57ccc5d0926fdf
Closes-Bug: #1464491
The current format is just copy-paste after auto-conversion and very
inconsistent. Move discussion of each option into a section and
reword some slightly so they read more clearly. Group some together
into a section+sub-sections, such as the logging and ip-version option
discussions.
Add a top table-of-contents for the major sections, and then a
separate toc for each of the configuration options that are discussed
in detail.
Change-Id: Iddd27cb54f1d9f062b9c47ff9ad6a2bef3650d6b
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>
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
Make it possible for someone to config
PIP_UPGRADE=True
in local.conf and thus force pip_install calls to upgrade. In
automated testing this is probably a bad idea, but in manual testing
or situations where devstack is being used to spin up proof of
concepts having the option to use the latest and greatest Python
modules is a useful way of exploring the health of the ecosystem.
To help with visibility of the setting, and section has been added
in configuration.rst near other similar settings.
Change-Id: I484c954f1e1f05ed02c0b08e8e4a9c18558c05ef
Adds USE_VENV to globally enable/disable use of virtual environments.
ADDITIONAL_VENV_PACKAGES is used to manually add packages that do not
appear in requirements.txt or test-requirements.txt to be installed
into each venv. Database Python bindings are handled this way when
a dataabse service is enabled.
Change-Id: I9cf298b936fd10c95e2ce5f51aab0d49d4b7f37f
This is the first step in the log file cleanup. If SCREEN_LOGDIR
is still set, symlinks will be created in the old screen log directory
so things like the devstack-gate log collector continues to work.
bp:logging-and-service-names
Change-Id: I3ac796e322a18dbd0b8b2310a08310ca159d7613
Ib0538bdd23b17e519b9c917018ccc9fa8c6425c5 removed the option
API_RATE_LIMIT. So don't mention it in the documentation.
Change-Id: I9df67c3dd1b800f6a51de2cd78aeaad10ca38f7e
Also reformat common configuration variables to have an additional
header level which makes it easy to direct link to specific
configuration vars when directing someone.
Reformat header markup to us a more standard == = - for h1, h2, h3
Change-Id: I10bac5a93529cdfbcde0a05f9ebdbc1799d403cd
