openstack team mailing list archive

[Loic Dachary <loic@xxxxxxxxxxxx>]

> Another item that we need to discuss is extensibility of this API.

Hi,

Here is a proposal, which we could discuss further during the meeting.

GET extension=XXXX&param1=foo&param2=bar

The API looks up /usr/share/ceilometer/extensions/XXXX.py and loads it. The XXXX module defines a query function that takes the following arguments:

* QUERY_STRING (i.e. extension=XXXX&param1=foo&param2=bar )
* a handler to the storage
* a pointer to the configuration (assuming there is a /etc/ceilometer.ini file, for instance)

The query function would return the result. For instance { 'in': 20001, 'out': 489324 } if asked for aggregated network usage.

Multiple extensions directories could be specified and searched, allowing a mixture of extensions provided in ceilometer and custom extensions to address specific needs or to mature an new extension.

The primary benefit of defining extensions in this way is to avoid complex conventions for aggregations or other advanced operations. If the API was to impose a syntax or conventions to say "sum this field and this one and display the result ordered in this way and grouped by this field and this one", it would be redundant with the query language of the underlying data. For instance, if using mongodb, it would be difficult to expose all the features provided by http://www.mongodb.org/display/DOCS/Aggregation or http://www.mongodb.org/display/DOCS/MapReduce

Cheers

-- 
Loïc Dachary         Chief Research Officer
// eNovance labs   http://labs.enovance.com
// ✉ loic@xxxxxxxxxxxx  ☎ +33 1 49 70 99 82