> 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¶m1=foo¶m2=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¶m1=foo¶m2=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
// ✉ l...@enovance.com ☎ +33 1 49 70 99 82
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
