openstack/devstack - devstack - OpenDev: Free Software Needs Free Tools

This removes all of the ironic code from the devstack tree, in favor of
the devstack plugin in Ironic's tree.
Depends-On: I659e3de5c64df798441798ff48ba5c9c0506585a
Depends-On: I2c52bc014f1b0dbc6b0ae22a4deb4132b4c28621
Change-Id: I5125fce295c79600781469c2f48bea80e7600081

Add instructions on creating a user to the documentation, and call out
that the standard cloud-users are probably ok too
Change-Id: I1119a43f1d5ae7c0c208bf0cc16e2f7bee29a69d

Thanks to lifeless, pip now implicitly has a wheel cache so that it
builds a wheel before every install, and uses that cache. All our
clever attempts at manually doing wheelhouse things is actually
bypassing the existing cache and making things take longer.
We should remove all of this code and just let pip do this thing,
which is does very well, and get out of the way.
Change-Id: Ia140dc34638d893b92f66d1ba20efd9522c5923b

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

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

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

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

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

Once the trove code is copied into the trove repo and it is used
as a devstack-plugin, we can remove trove-specific code from
devstack.
Change-Id: I8f9f1a015edb7ec1033e2eaf0b29ab15d89384ce
Depends-On: I3506dec0e6097f9c2e9267110fdfb768faa23c85

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

Preparing to refactor lib/neutron to support Neutron as the default
network config. lib/neutron will be renamed internally and refined
to support a couple of specific configurations.
Change-Id: I0d3773d14c4c636a4b915734784e7241f4d15474

This document explains the steps to configure Load-Balancer in
kilo.
Change-Id: Ic8c2f3cca80e331b7275f689051c07d863d918ea
Depends-On: I64a94aeeabe6357b5ea7796e34c9306c55c9ae67

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

contributing.rst doesn't add very much over the extant HACKING.rst, so
move some of the unique bits into HACKING.rst and then link that into
the documentation.
Change-Id: I0530f38eda92f8dd374c0ec224556ace6e679f54

* config/INI functions from functions-common to to inc/ini-config
* local.conf meta-config functions from lib/config to inc/meta-config
Change-Id: I00fab724075a693529273878875cfd292d00b18a

diskimage-builder is a utility rather than a service, and is already
installed in devstack via pip when required.
lib/dib was created to allow an image to be created during a devstack
run for the heat functional tests, however this approach is no longer
being taken and there are no other known uses for lib/dib.
This change removes lib/dib and moves the pip mirror building to
lib/heat so that snapshot pip packages of the heat agent projects can
be made available to servers which the heat functional tests boot.
This also removes tripleo-image-elements, which has never
been utilised, and since images won't be created
during heat functional test runs it is no longer required.
Change-Id: Ic77f841437ea23c0645d3a34d9dd6bfd1ee28714

Nova has the ability to do remote interactive consoles but there is no
easy way to enable this in devstack. This change defines a service
called n-serial to enable the service. Documentation is added to a
new guide on nova, describing how to set further options in local.conf
Change-Id: I401d94b2413c62bfae9b90d2214d77bd4cfc15d5

Now that we have a working external plugin mechanism stackforge
projects definitely don't need to be directly in devstack. These were
largely unused previously anyway.
Change-Id: I300686b2ac976d9b454404842b3f210fd7c239d9

Now that we have a patch to make this pluggable [1], lets remove this
from the devstack repository.
[1] https://review.openstack.org/#/c/153700/
Change-Id: Ia23f99476ec16df9cc12f63864189835a09eb644

Add a document with procedure to configure KVM-based nested
virtualization on the physical host and to configure DevStack (in a VM)
to take advantage of it.
Current topics:
 - Configure nested virt on Intel hosts
 - Configure nested virt on AMD hosts
 - Expose virt extensions to DevStack VM
 - Ensure DevStack VM is using KVM
Change-Id: Ibe6fa482cc0d51183438d99680a0e10d0da652cb

Updated the supported OS release versions mentioned in stack.sh to be
consistent with what is listed in doc/source/index.rst
Change-Id: Ie9045927779a063865115e3aff1b92450a104946
Closes-Bug: #1414205 

This has been deleted from the nova tree, we should purge it from
devstack, as it will not work any more.
Change-Id: I20501fec140998b91c9ddfd84b7b10168624430a

* Re-work the old banner logo for the Sphinx docs
* Remove the remaining leftover assets from the old web site
So this is one possibility, I retained the other logo files so we have
options to play with.
Change-Id: Iac15899780072450dc30600a719283c0e2b0c0ae

Change-Id: I75f30a6809a6276dbd8a61e73535913be63b54f0

Adds initial support for configuring and starting the tuskar-api
service.
To enable, add the following to your localrc:
enable_service tuskar
enable_service tuskar-api
The aim of this addition is to provide a more accessible (non devtest)
way for developers to run up tuskar in a familiar devstack environment.
See the official repos for more information:
https://github.com/openstack/tuskar/
https://github.com/openstack/python-tuskarclient
Change-Id: Id0c3c0d3a38100c66dbe6e3adf1f715162f99742

Update the form of the links to other documents in the tree;
the generated HTML links must remain in the original form.
The layout is changed from the previous tables to a more Sphinx-y
TOC-like list.
Also editorial changes to the index page and guide titles
Change-Id: I52df0cc542754c386fb3c99d9efdf2524c11bf48

This updates the form of the links to other documents in the tree;
the generated HTML links must remain in the original form.
Change-Id: I6c2179e3b7cb5b8e2589ede84ab7d02340812e80

There were a lot of artifacts left from the HTML translation.
The toctree at the end is to suppress the errors until the remaining
docs are cleaned up.
Change-Id: I4a8f29f0be524d0a15c7c6f590ffc3ceed6ff811

Change-Id: I305414a5a38c6837a765110e726771ba2f94fe45

Change-Id: I2fe6aac7caec21af26983636d6ec827b3525ee15

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