Exclude tests directory from installation.

This fixed bug #1146340 by excluding tests packages.

Change-Id: Id892c0a2e521a199a9ac42ed8d3729e17fffb5bd
HBase storage driver, initial version.

This is a new storage driver that supports storing of Ceilometer
data in an HBase backend. This version does not have metaquery
support yet.

Implements: blueprint hbase-storage-backend
Change-Id: Id3e7ec01434b1be30cce4f91b39461fc389a000f
Merge "HBase storage driver, initial version."
Kwapi pollster silently return no probre if keystone endpoint is not present

Fixes bug 1105404

Change-Id: Ib2673215ca1075d04283492d9e08540f9f786d08
api: run list meters tests against SQL backend too

Change-Id: Ide08d0e92aa29a0d79333d1e02e8184a2f6d132d
Signed-off-by: Julien Danjou <julien@danjou.info>
api: run list users test against SQL backend too

Change-Id: I89a0d970ac124c6ff51c8e8f9389b7dda7403462
Signed-off-by: Julien Danjou <julien@danjou.info>
api: run list_projects tests against SQL backend too

Change-Id: Id656537f74ebb636147fb8e6762a65652ad5c151
Signed-off-by: Julien Danjou <julien@danjou.info>
api: run compute duration by resource on SQL backend

Change-Id: Id5aa0bc2b24bb7d3e521d51b2b7777b99ea418e5
Signed-off-by: Julien Danjou <julien@danjou.info>
Merge "Exclude tests directory from installation."
Merge "api: run list meters tests against SQL backend too"
Merge "api: run list users test against SQL backend too"
Merge "api: run list_projects tests against SQL backend too"
Merge "api: run compute duration by resource on SQL backend"
Fix an invalid test in the storage test suite

The test_by_user_period test is looking for the first
result set to come back with the wrong timestampe, and
not noticing that most of the test isn't even being
run. Be more explicit about the expected results.

Change-Id: I47e7699c877819d98f66d47dc85662f26767abd6
Signed-off-by: Doug Hellmann <doug.hellmann@dreamhost.com>
Merge "Fix an invalid test in the storage test suite"
Initial implementation of ceilometer-alarm

The implemented use case is raising an alarm (i.e. executing something)
as soon as a cumulative counter is above or below a certain threshold.

Alarms are stored in alarms.json inside the config directory.

The result of the "statistic" during a "period" is compared
to the alarm "threshold" with the operator in "comparaison_operator"
field of the alarm.

the statistic is calculated with get_meter_statistics() of the storage
connection.

The criteria handled to check if the alarm threshold needs to be checked
for a meter are for now only:
- counter_name
- resource_id

When a alarm is triggered a shell script is executed, same things when the
alarm is untriggered

The used shell script are stored in fields "ok_action" and "alarm_action" of the
alarm description.

The alarm status stays in memory as long as the alarms aren't stored in a
persistante storage.

Change-Id: I2dfebc30a47576e83906a6d4011ce5d52041e901