Everything else in our documentation is RST, we should convert the
Readme to RST as well (as github supports this, so it's fine to read
it there)
Change-Id: If2aabf629affc09b5daa570f4ca3bdf268cb53b0
This all started with an investigation into Fedora's use of ecua2ools
package. This package is a bit of a nightmare because it pulls in a
lot of other system-python packages.
For Ubuntu, this package was removed in
I47b7e787771683c2fc4404e586f11c1a19aac15c. However, it is not
actually a "pure python" package as described in that change, in that
it is not installable from pypi. I can't see how you could actually
run exercises/euca.sh on Ubuntu unless you installed euca2ools by hand
-- ergo I suggest it is totally unused, because nobody seems to have
reported problems.
In the mean time, ec2 api has moved to a plugin [1] anyway where the
recommendation in their README is to use the aws cli from amazon.
Thus remove all the parts related to EC2 and ecua2ools from base
devstack.
[1] https://git.openstack.org/cgit/openstack/ec2-api
Change-Id: I8a07320b59ea6cd7d1fe8bce61af84b5a28fb39e
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
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>
Review https://review.openstack.org/#/c/192154/ removed support for RPC backends
other than RabbitMQ, but we should still document how to disable rabbit.
Change-Id: I1fd64b5f02573c58d7b0d1005c39a22c459a09a5
Part of what was decided at summit is devstack needs to return to a
more opinionated stance, the following removes support for non
RabbitMQ messaging. RabbitMQ is used by over 95% of our community
(statistically all of it), so it's a pretty clear line to draw that
this shouldn't be in tree.
iniset_rpc_backend will be our stable hook for other projects that
want to implement this out of tree. The burden on creating those out
of tree plugins will be on those that wish to support those
alternative stacks.
Change-Id: I8073a895c03ec927a2598eff6c2f01e5c82606fc
The Multi-Node Setup guide in README.md
https://github.com/openstack-dev/devstack/tree/master#multi-node-setup
guides users to use
SCHEDULER=nova.scheduler.simple.SimpleScheduler
where the SimpleScheduler doesn't actually exist in nova. Even
though this is just an example, it is misleading enough for a
beginner to put SimpleScheduler into local.conf. The resulting
error message where n-sch fails to start
ImportError: No module named simple
Isn't intuitive enough and may takes the beginner long time to
locate what's wrong.
This patch replaces SimpleScheduler with a real existing
FilterScheduler in nova.
Change-Id: I14a2a5c0604ce08a498accfc3a795c1c9aa3e642
Closes-bug: #1453186
Inspired by keystone and rcbops-cookbooks's nova scripts,
this review adds apache2 templates for two of the Nova
services. Also add code in lib/nova to switch between
the old and new ways to these two services. The patch
depends on the Nova review mentioned below as the two
scripts that are needed will be in Nova's repository.
TODO for later would be to switch on NOVA_USE_MOD_WSGI
when ENABLE_HTTPD_MOD_WSGI_SERVICES is switched on.
Related Nova blueprint:
https://blueprints.launchpad.net/nova/+spec/run-nova-services-under-apache2
Depends-On: Idd7d3d1b3cc5770cdecea7afe6db3c89d5b2c0d0
Change-Id: I9fc0c601db2776d3e9084be84065e728e3f5d414
The readme currently states that a compute node in a multi-node setup
requires the glance-api service to be enabled. But actually
the glance-api service is only required on the controller node where
glance-registry is running.
Running the glance-api service on a node without glance-registry will
even lead to a failure of glance-api, as the glance cache directory
will not be created without enabling glance-registry.
Change-Id: Ie92533f3333f3fe3e2d747762e60f2f42a233e79
Closes-bug: #1441198
In I78d51f04ed01da4ce8aa0e127be028f969d3b4f8 we turned off installing
tempest because we install it on stable branches where the stable reqs
do not equal the tempest master (branchless) reqs.
Leave this off by default since that is the behaviour we have in the
gate, and make default devstack as similar to the gate as possible. But
add an option to install tempest by default so developers can opt and
reproduce the previous behaviour.
Update the tempest section of the README with how to run tempest tests
and how to install tempest if desired.
Change-Id: Ie4ea7335a57917244873ec54658ca269ab765ce1
These have been emitting deprecated warnings for over a full release cycle:
Q_AGENT_EXTRA_AGENT_OPTS, Q_AGENT_EXTRA_SRV_OPTS, CINDER_MULTI_LVM_BACKEND
Change-Id: I3aa5cabd6ce3a0072cba08bbca1ad23d4a831219
Make the default run mode of Keystone HTTPD + mod_wsgi. This will
enable gating on Keystone under mod_wsgi.
Depends On: https://review.openstack.org/#/c/100764/
Change-Id: I4b664a1d6c9bbb1ff999158f3a8c8ab3bd8d891b
Added a global toggle for enabling HTTPD + mod_wsgi for services
that default deploy to running under Apache. When the variable
``ENABLE_HTTPD_MOD_WSGI_SERVICES`` is set to ``True`` any service
that recommends deploying under HTTPD + mod_wsgi, will be run
under Apache.
If ``ENABLE_HTTPD_MOD_WSGI_SERVICES`` is set to ``False`` the
any service that is defaulted to running under HTTPD + mod_wsgi
will (if capable) be run in an alternate deployment strategy (e.g.
eventlet).
Updated Swift and Keystone to have individual toggles for deploying
under HTTPD + mod_wsgi. This is done to allow for gate to run on
the services under mod_wsgi where appropriate. Toggles are
``KEYSTONE_USE_MOD_WSGI`` and ``SWIFT_USE_MOD_WSGI`` and are both
defaulted to "False" (do not deploy under HTTPD + mod_wsgi).
Change-Id: Id3b121b8f1cde369d184b586e0d875bdbda34813
The documentation stated that, to enable Keystone running on Apache,
one should set:
APACHE_ENABLED_SERVICES+=keystone,swift
However, it actually works with:
APACHE_ENABLED_SERVICES+=key,swift
Change-Id: I8cc92e9426d7fc3117b30df01babdb50576328af
Closes-bug: #1311461
with I1c9bea2fdeebc4199c4f7d8fca4580a6fb7fed5b nova removed
docker from it's driver tree.
We shouldn't have driver support inside of devstack that's not
part of upstream projects (this has been a line we've been
pretty clear on with Neutron drivers in the past).
Remove docker driver accordingly.
Change-Id: Ib91d415ea1616d99a5c5e7bc3b9015392fda5847
The various EXTRA_xxx_OPTS variables will be removed in the Juno
development cycle, change the README to reflect the new way for
the Neutron variables.
Change-Id: Ic84da4a9b5a83e66cf0b57d643a87691f15517f0
In Havana, Neutron has now a Metering Agent which gets meters from
virtual routers.
This patchs aims to allow devstack using this new service.
Change-Id: I17ad83799d60384247b98cc8a93ac032f641c721
Signed-off-by: Emilien Macchi <emilien.macchi@enovance.com>
The git repositories on github for openstack are mirrors of the primary
repositories, which are hosted on git.openstack.org, so switch as much
as I can to using the primary, rather than the github mirror.
Change-Id: Idcfda49a691582055256b830c61e098f4a271339
The current existing phases "post-config" and "extra" are not
sufficient to allow local.conf overrides to extra type services
because they run after the services are installed and configured.
This commit introduces a new phase called "post-extra" that runs
after these existing phases. With this change, users are able to
leverage local.conf to provide overridden options to services
like Tempest.
Change-Id: I5d758eebfda804dd1d8cbc3d5cc35ef4dcc8c96f
Closes-Bug: #1249085
Add hooks to stack.sh, unstack.sh and clean.sh to call the extras.d
scripts at multiple points in stack.sh. This allows these scripts to
perform installation and startup tasks at similar times as they would
if integrated into stack.sh.
extras.d/70-tempest.sh is present as an example of the structure
of these scripts.
See extras.d/README.md for more information.
Change-Id: Ic1fe522559b94d204d6c0319a2e3d23684c8d028
This defines a new local.conf file that is designed to take the place of all
of the 'pass-through'[1] configuration options that have been defined in DevStack.
* new local.conf file can contain multiple config file settings to be
merged in to existing project config files
* localrc can be embedded into local.conf and will auto-extract if
localrc does not exist
* Adds functions get_meta_section(), get_meta_section_files(),
merge_config_file() and merge_config_group()
* Adds EXTRA_OPTS, EXTRA_BAREMETAL_OPTS, Q_DHCP_EXTRA_DEFAULT_OPTS and
Q_SRV_EXTRA_DEFAULT_OPTS to the deprecated warning list at the end of stack.sh
[1] Pass-through options are those that do not configure or change DevStack's behaviour
but simply set a value in a project config file. This includes most of the EXTRA_XXX_OPTS
configuration variables.
Change-Id: I367cadc86116621e9574ac203aafdab483d810d3
Automatically creating a new user account is not always the right course
of action when stack.sh is running as root. Plus, the re-exec did not
work correctly in some cases.
* Create tools/create-stack-user.sh to set up a suitable user
for running DevStack
* Abort stack.sh and unstack.sh if running as root and suggest creating a
suitable user account.
Change-Id: I5d967c00c89f32e861449234ea8fe19261cd9ae3
* Add basic support for hypervisor plugins in lib/nova_plugins
* Add lib/nova_plugins/hypervisor-docker to use Docker as a Nova
hypervisor.
* Add tools/install_docker.sh to install the Docker daemon and
registry container, download base image and import
* Configure Nova to use docker plugin
* Add docker exercise and skip unsupported ones
Nova blueprint: new-hypervisor-docker
Change-Id: I9e7065b562dce2ce853def583ab1165886612227
The following localrc will launch only heat in standalone mode
and allow it to provision within the openstack specified by
the configured keystone endpoint:
HEAT_STANDALONE=True
ENABLED_SERVICES=rabbit,mysql,heat,h-api,h-api-cfn,h-api-cw,h-eng
KEYSTONE_SERVICE_HOST=...
KEYSTONE_AUTH_HOST=...
Change-Id: I0d8a541fc9d592577423b074c789829f8b8d6702
Sean Dague