devstack/extras.d
Sébastien Han 36f2f024db Implement Ceph backend for Glance / Cinder / Nova
The new lib installs a full Ceph cluster. It can be managed
by the service init scripts. Ceph can also be installed in
standalone without any other components.
This implementation adds the auto-configuration for
the following services with Ceph:

* Glance
* Cinder
* Cinder backup
* Nova

To enable Ceph simply add: ENABLED_SERVICES+=,ceph to your localrc.
If you want to play with the Ceph replication, you can use the
CEPH_REPLICAS option and set a replica. This replica will be used for
every pools (Glance, Cinder, Cinder backup and Nova). The size of the
loopback disk used for Ceph can also be managed thanks to the
CEPH_LOOPBACK_DISK_SIZE option.

Going further pools, users and PGs are configurable as well. The
convention is <SERVICE_NAME_IN_CAPITAL>_CEPH_<OPTION> where services are
GLANCE, CINDER, NOVA, CINDER_BAK. Let's take the example of Cinder:

* CINDER_CEPH_POOL
* CINDER_CEPH_USER
* CINDER_CEPH_POOL_PG
* CINDER_CEPH_POOL_PGP

** Only works on Ubuntu Trusty, Fedora 19/20 or later **

Change-Id: Ifec850ba8e1e5263234ef428669150c76cfdb6ad
Implements: blueprint implement-ceph-backend
Signed-off-by: Sébastien Han <sebastien.han@enovance.com>
2014-07-23 16:13:45 +02:00
..
50-ironic.sh Integration testing preparation for Ironic 2014-03-14 13:44:00 -07:00
60-ceph.sh Implement Ceph backend for Glance / Cinder / Nova 2014-07-23 16:13:45 +02:00
70-gantt.sh Add support for Gantt 2014-01-30 14:47:50 -07:00
70-marconi.sh Add marconi support to devstack 2013-11-27 11:09:21 +01:00
70-sahara.sh Rename all Savanna usages to Sahara 2014-03-12 22:25:20 +04:00
70-trove.sh Renamed file 70-trove to 70-trove.sh 2014-01-29 15:27:18 +00:00
80-opendaylight.sh Invoke create_nova_conf_neutron from odl-compute post-install 2014-06-16 10:27:42 -04:00
80-tempest.sh Complete moving Keystone setup out of keystone_data.sh 2014-03-10 15:17:30 -05:00
README.md Add pre-install phase for extras.d plugins 2014-07-09 11:35:16 -05:00

Extras Hooks

The extras.d directory contains project dispatch scripts that are called at specific times by stack.sh, unstack.sh and clean.sh. These hooks are used to install, configure and start additional projects during a DevStack run without any modifications to the base DevStack scripts.

When stack.sh reaches one of the hook points it sources the scripts in extras.d that end with .sh. To control the order that the scripts are sourced their names start with a two digit sequence number. DevStack reserves the sequence numbers 00 through 09 and 90 through 99 for its own use.

The scripts are sourced at the beginning of each script that calls them. The entire stack.sh variable space is available. The scripts are sourced with one or more arguments, the first of which defines the hook phase:

source | stack | unstack | clean

source: always called first in any of the scripts, used to set the
    initial defaults in a lib/* script or similar

stack: called by stack.sh.  There are four possible values for
    the second arg to distinguish the phase stack.sh is in:

    arg 2:  pre-install | install | post-config | extra

unstack: called by unstack.sh

clean: called by clean.sh.  Remember, clean.sh also calls unstack.sh
    so that work need not be repeated.

The stack phase sub-phases are called from stack.sh in the following places:

pre-install - After all system prerequisites have been installed but before any
    DevStack-specific services are installed (including database and rpc).

install - After all OpenStack services have been installed and configured
    but before any OpenStack services have been started.  Changes to OpenStack
    service configurations should be done here.

post-config - After OpenStack services have been initialized but still before
    they have been started. (This is probably mis-named, think of it as post-init.)

extra - After everything is started.