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
