Ceilometer/blueprints/multi-dimensions

Launchpad Entry: tbd
Created: 27 Nov 2012
Contributors: Nick Barcet

Summary

In order to be able to perform smart and fast aggregation in the API, we need to be able to perform queries that would aggregate counters based on additional keypair values than the simple tenant/user/ressource triplet. This spec proposes to handle meta data in a new and different way that would allow to solve this.

Release Note

It is now possible to request aggregated value based on additional "dimensions" for each counters/meters in Ceilometer

User stories

John would like to retrieve the aggregated number of objects accross all of his containers named xxx
Peter would like to know his average cpu usage for all instance type yyyy

Assumptions

We assume here that the way metadata have been used so far can be modified with no user impact when upgrading from from v0.1
We assume that metadata used so far are not containing nested values and can therefore be translated into keypairs

Design

This blueprint assumes 3 changes:

1. Switching from meta-data to dimensions

The proposal is to replace the current json formated meta data into a list of keypairs.

Meta-data, which could then be thought of as dimensions, would then be expressed as a simple list of <key>:<value>, thus allowing for more efficient indexing and aggregation regardless of the underlying storage engine.

If meta-data cannot be replaced, then an additional "dimensions" field would be added to the schema.

2. Adding dimension filters to the API

Each meters related API call would have one additional optional parameter:

dimensions -- list of keypairs as "(key1, value1), .. (keyN, valueN)"

Which would allow to

3. Adding an average function

The following API calls would be added to the API

GET /v1/projects/(project)/meters/(meter)/volume/average
GET /v1/resources/(project)/meters/(meter)/volume/average

Implementation

Strorage design

In the case of a relational database storage engine, the dimensions would be stored in a separate table as follow

+------------+       +------------+
| Dimensions |       | Event      |
+------------+       +------------+
| EventID    |N-----1| EvenID     |
| Key        |       | ResourceID |
| Value      |       | .....      |  
+------------+       | .....      |

Code Changes

TBD

Migration

If we decide to modify the structure of the existing meta-data, we need to provide a procedure to translate existing meta-data information to the new format.

Test/Demo Plan

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.