DevStack has a couple of plugin mechanisms to allow easily adding support for additional projects and features.
These relatively new hooks are an extension of the existing calls from stack.sh
at the end of its run, plus unstack.sh
and clean.sh
. A number of the higher-layer projects are implemented in DevStack using this mechanism.
The script in extras.d
is expected to be mostly a dispatcher to functions in a lib/*
script. The scripts are named with a zero-padded two digits sequence number prefix to control the order that the scripts are called, and with a suffix of .sh
. DevSack reserves for itself the sequence numbers 00 through 09 and 90 through 99.
Below is a template that shows handlers for the possible command-line arguments:
# template.sh - DevStack extras.d dispatch script template # check for service enabled if is_service_enabled template; then if [[ "$1" == "source" ]]; then # Initial source of lib script source $TOP_DIR/lib/template fi if [[ "$1" == "stack" && "$2" == "pre-install" ]]; then # Set up system services echo_summary "Configuring system services Template" install_package cowsay elif [[ "$1" == "stack" && "$2" == "install" ]]; then # Perform installation of service source echo_summary "Installing Template" install_template elif [[ "$1" == "stack" && "$2" == "post-config" ]]; then # Configure after the other layer 1 and 2 services have been configured echo_summary "Configuring Template" configure_template elif [[ "$1" == "stack" && "$2" == "extra" ]]; then # Initialize and start the template service echo_summary "Initializing Template" ##init_template fi if [[ "$1" == "unstack" ]]; then # Shut down template services # no-op : fi if [[ "$1" == "clean" ]]; then # Remove state and transient data # Remember clean.sh first calls unstack.sh # no-op : fi fi
The arguments are:
extras.d
hooks; this replaces directly sourcing the lib/*
script.stack.sh
three times for different phases of its run:
unstack.sh
before other services are shut down.clean.sh
before other services are cleaned, but after unstack.sh
has been called.
Hypervisor plugins are fairly new and condense most hypervisor configuration into one place.
The initial plugin implemented was for Docker support and is a useful template for the required support. Plugins are placed in lib/nova_plugins
and named hypervisor-<name>
where <name>
is the value of VIRT_DRIVER
. Plugins must define the following functions:
install_nova_hypervisor
- install any external requirementsconfigure_nova_hypervisor
- make configuration changes, including those to other servicesstart_nova_hypervisor
- start any external servicesstop_nova_hypervisor
- stop any external servicescleanup_nova_hypervisor
- remove transient data and cache