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>
Zaqar's devstack code has been moved into a plugin in the Zaqar repo.
This patch removes the remaining code from devstack.
Depends-On: Iceefabb6cd528b23075a91e8039b8264eb3f33f5
Change-Id: Ifcf54fa2d4a5bf49b6757b593bb70cdeda8edb2a
Cinder API v1 will be removed Mitaka so we don't need to setup it be
default.
To enable Cinder API v1 you need to set CINDER_ENABLE_V1_API=True in
your Devstack config.
Related-Bug: #1467589
Depends-On: I6916eb3e4b7c85f37be8b365b11ca8b48f88177c
Change-Id: I0754e357433cfcd9fde7e937a4a1b440580b6289
The ceilometer project is moving to using a devstack plugin rather
than having ceilometer in the base devstack. This is to allow
greater control and flexibility.
Change-Id: I413ab159474b7d7231ad66d3a482201f74efe8a8
I had to poke around for awhile to find /var/log/cloud-init-output.log
so I figured I'd add a sentence in the docs about using that.
Change-Id: I8bb6cb730032e41661ee443da816cbea2b28f76d
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
The change fix multi-node doc to use SERVICE_HOST.
It resolves duplicate IP address.
Closes-Bug: #1485159
Change-Id: If86393e9a37bcb911a9aa125829cd8ce684edd9f
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
The multinode guide erroneously said to enable n-api on the worker
nodes, which is a typo. n-api-meta is the thing that's needed.
Change-Id: I733896681f7f6fe3bea0fdeeb8ffc9033d7fc761
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>
Once the Sahara related code moved to Sahara repo and used, we can
remove Sahara specific code from Devstack.
Partial-Implements: bp sahara-devstack-intree
Change-Id: I34412b5cb2e86944b8555b8fd04b43556eb2bbe6
Depends-on: I2e00b2ebc59dd3be6a0539dea2985f2e801a1bd7
Depends-on: I07c3fede473030e8a110cbf5a08309f890905abf
In documentation like this (which is a huge boon) we should strive to be
as explicit and helpful as possible, so this change tries to be more
clear about what a project.yaml is and where one might go to create it
or change it.
Change-Id: Ia66a361fc7d79e511afa3ad903fffb122b86998b
The devstack plugin docs mostly referred to in tree plugins, which is
honestly something we don't want people doing. Instead restructure the
whole document to talk about external plugins as the only kinds of
plugins, and focus on a workflow to make that easy for people to work
through.
This also adds a plugin-registry page to start listing known plugins
somewhere centrally. Some sample content was added, hopefully people
will submit patches to include their plugins.
This does drop the section on hypervisor plugins. That's not currently
something that we expect a ton of people to work on, so diving into
the code for this should be fine.
Change-Id: Ifc0b831c90a1a45daa507a009d1dcffcd6e2deca
That'll make things more clear that with the provider networking
feature in DevStack, FIXED_RANGE will be a routed IPv4 subnet that gives
routed IPv4 addresses to instances without using floating IPs.
Change-Id: Ie26d75ac5ff285a25762c4f61fd9800b0382886b
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
Add a note about running openrc through bash for import into zsh, as
shown by Chmouel Boudjnah in I5b6c8cfedcdd36efb4cbc91831501ee5c9c3b1d1
Change-Id: I5f1c9fc3fdc045cf6fb69af13f6264a81bf5f763
Closes-Bug: #1460656
Fedora 20 will reach end of life on 23-JUN-2015[1]; remove it as
supported distribution. Add Fedora 22 where applicable.
- stack.sh: Remove Fedora 20 from list of supported distributions.
- files/rpms/general: Remove 'f20' from NOPRIME.
- lib/ceph: Remove 'f20' from the check_os_support_ceph()
function.
- doc/source/index.rst: s/Fedora 20/Fedora 21/
[1] https://lists.fedoraproject.org/pipermail/devel-announce/2015-May/001586.html
Change-Id: I8f2e1ddc24c071754b1cceb5bed5bdafdc9d9f79
