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
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>
The motivation for this conversion is to have DevStack's docs be
generated using a more familair workflow for OpenStack projects, using
Sphinx.
Changing from raw HTML to RST will also make it easier to contribute
more documentation, as well as making edits less of a hassle.
The majority of the work was done by using Pandoc to convert from HTML
to RST, with minor edits to the output to remove errors in Sphinx.
Change-Id: I9636017965aeade37b950ddf5bdb0c22ab9004bd