Skip to content

Latest commit

 

History

History
222 lines (162 loc) · 6.69 KB

PLUGINS.rst

File metadata and controls

222 lines (162 loc) · 6.69 KB
Raw

Modular Grenade Architecture

Grenade was originally created to demonstrate some level of upgrade capacity for OpenStack projects. Originally this just included a small number of services.

Proposed new basic flow:

  • setup_grenade - all the magic setup involved around err traps and filehandle redirects - setup devstack trees
  • setup_base - run stack.sh to build the correct base environment
  • verify_base - for project in projects; do verify_project; done
  • resources.sh create
  • resources.sh verify
  • shutdown - for project in projects; do shutdown; done
  • snapshot.sh pre_upgrade (NOT YET IMPLEMENTED)
  • resources.sh verify_noapi
  • upgrade ...
  • resources.sh verify
  • verify_target
  • resources.sh destroy

Modular Components

Assuming the following tree in target projects:

devstack/    - devstack plugin directory
   upgrade/   - upgrade scripts
       settings   - adds settings for the upgrade path
       upgrade.sh
       snapshot.sh - snapshots the state of the service, typically a
          database dump (NOT YET IMPLEMENTED)
       from-juno/ - per release
       within-juno/
       from-kilo/
       within-kilo/
       resources.sh
This same modular structure exists in the grenade tree with::
grenade/
projects/
10_ceilometer/
settings upgrade.sh

resources.sh

resources.sh is a per-service resource create / verify / destroy interface. What a service does inside a script is up to them.

You can assume your resource script will only be called if your service is running in an upgrade environment. The script should return zero on success for actions, and nonzero on failure.

Calling Interface

The following is the supported calling interface

  • resources.sh create

    creates a set of sample resources that should survive upgrade. Script should exit with a nonzero exit code if any resources could not be created.

    Example: create an instance in nova or a volume in cinder

  • resources.sh verify

    verify that the resources were created. Services are running at this point, and the APIs may be expected to work.

    Example: use the nova command to verify that the test instance is still ACTIVE, or the cinder command to verify that the volume is still available.

  • resources.sh verify_noapi

    verify that the resources are still present. This is called in the phase where services are stopped, and APIs are expected to not be accessible. Resource verification at this phase my require probing underlying components to make sure nothing has gone awry during service shutdown.

    Example: check with libvirt to make sure the instance is actually created and running. Bonus points for being able to ping the instance, or otherwise check its live-ness. With cinder, checking that the LVM volume exists and looks reasonable.

  • resources.sh destroy

    Resource scripts should be responsible and cleanup all their resources when asked to destroy.

Calling Sequence

The calling sequence during a grenade run looks as follows:

  • # start old side
  • create (create will be called during the working old side)
  • verify
  • # shutdown all services
  • verify_noapi
  • # upgrade and start all services
  • verify
  • destroy

The important thing to remember is verify/verify_noapi will be called multiple times, with multiple different versions of OpenStack. Those phases of the script must not be rerunnable multiple times.

While create / destroy are only going to be called once in the current interface, bonus points for also making those idempotent for resiliancy in testing.

Supporting Methods

In order to assist with the checks listed the following functions exist:

resource_save project key value
resource_get project key

This allow resource scripts to have memory, and keep track of things like the allocated IP addresses, IDs, and other non deterministic data that is returned from OpenStack API calls.

Environment

Resource scripts get called in a specific environment already set:

  • TOP_DIR - will be set to the root of the devstack directory for the BASE version of devstack incase this is needed to find files like a working openrc
  • GRENADE_DIR - the root directory of the grenade directory.

The following snippet will give you access to both the grenade and TARGET devstack functions:

source $GRENADE_DIR/grenaderc
source $GRENADE_DIR/functions

Best Practices

Do as many actions as non admin as possible. As early as you can in your resource script it's worth allocating a user/project for the script to run as. This ensures isolation against other scripts, and ensures that actions don't only work because admin gets to bypass safeties.

Test side effects, not just API actions. The point of these resource survival scripts is to test that things created beyond the API / DB interaction still work later. Just testing that data can be stored / retrieved from the database isn't very interesting, and should be covered other places. The value in the resource scripts is these side effects. Actual VMs running, actual iscsi targets running, etc. And ensuring these things are not disrupted when the control plane is shifted out from under them.

Out of Tree Plugins

A grenade plugin can be hosted out of tree in a project tree, similar to external devstack plugins. There are a few subtle differences when this happens.

The plugin structure will live under $project/devstack/upgrade/ directory.

The plugin is enabled by adding:

enable_grenade_plugin <$project> <giturl> [branch]

To pluginrc in the GRENADE_DIR. An additional rc file was required due to sequencing of when plugin functions become available.

Changing Devstack Localrc

There is also a mechanism that allows a settings file change the devstack localrc files with the devstack_localrc function.

::
devstack_localrc <base|target> arbitrary stuff to add

Which will take all the rest of the stuff on that line and add it to the localrc for either the base or target devstack.

Example settings

The following is a reasonable example settings for out of tree plugin:

register_project_for_upgrade heat
register_db_to_save heat
devstack_localrc base enable_service h-api h-api-cfn h-api-cw h-eng heat
devstack_localrc target enable_service h-api h-api-cfn h-api-cw h-eng heat

This registers the project for upgrade, symbolicly enables the heat database for dump during upgrade, and adds the heat services into the service list for base and target.

It's expected that most settings files for out of tree plugins will need equivalent lines.