Grenade Resource Survivability

Integrated projects are required to participate in the Grenade upgrade testing harness. In addition to testing the upgrades themselves Grenade has facilities, called javelin, for testing survivability of resources through the upgrade process. Ceilometer needs to participate in this testing.

Problem description

To be certain that Ceilometer is robust across an upgrade it must be possible to process metrics and events from resources that exist before and after the upgrade. Grenade provides a feature named javelin which is designed to allow assertions that confirm resource A, present prior to the upgrade, is present after the upgrade.

In the Juno cycle Grenade is being updated to support javelin2 which, unlike the original javelin, should work well and has a declarative syntax for making assertions.

A previous spec describes adding basic Ceilometer support to Grenade. This spec is specifically about adding testing via javelin2.

Proposed change

Add support for Ceilometer resource checking to javelin2. This involves two types of changes (detailed below): Adding support for Ceilometer queries in the javelin code and adding Ceilometer specific entries to the resource definitions.

The main check that will be facilitated by javelin2 is ensuring the sanity of api queries with a time range that spans the entire window of time within which the Grenade test runs (e.g. -+12 hours from now).


It may be that Ceilometer queries do not map well to the resource model in use in javelin2. If this is the case then it might make sense to architect some other kind of before and after upgrade test specifically for Ceilometer. Doing so would be a shame, though. Better to make javelin2 more flexible.

Data model impact


REST API impact


Security impact


Pipeline impact


Other end user impact


Performance/Scalability Impacts

While Ceilometer has something of a reputation in this area, because it will already be running in the Grenade environment, no additional impact is expected by adding javelin tests.

Other deployer impact


Developer impact

As Ceilometer features grow or change, adjustments in the javelin2 check tests may need to be made.



Who is leading the writing of the code? Or is this a blueprint where you’re throwing it out there to see who picks it up?

If more than one person is working on the implementation, please designate the primary author and contact.

Primary assignee:


Other contributors:


Ongoing maintainer:


Work Items

  • Determine optimal form for handling ceilometer queries within javelin2. At a gross level there are two options: 1) Including the ceilometer queries as code within tempest.cmd.javelin itself, either built in or as plugin. 2) Representing the queries declaratively in a checks section of the resources.yaml file that could potenetially be used by other projects.

  • Add the queries (as described in Proposed change) in whatever form is chosen.

As a first pass, option 1 above is most expedient. If chosen the other options and the related review discussion should be considered for the future.

Future lifecycle

Ongoing maintenance of the Ceilometer portions of the javelin2 tests will be the responsibility of the Ceilometer project team.


These changes require javelin2 which was merged into Tempest on 30, May 2014.


Est quod est.

Documentation Impact