On Thu, May 10, 2012 at 9:22 AM, Loic Dachary l...@enovance.com wrote:
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=param1=fooparam2=bar
The API looks up /usr/share/ceilometer/extensions/.py and loads it.
The module defines a query function that takes the following arguments:
Andrew Bogott is doing some work with a standardized plugin mechanism for
Nova which will eventually be put in the common lib for all of the
projects. We should look at his work and use it, rather than inventing
something else. I think it will eventually use setuptools entrypoints,
which eliminates the need to worry about search paths.
Why would the extension be a query parameter, rather than a URL component?
That is, why wouldn't the extension just add new endpoints that could be
queried directly using their own API? Maybe I don't understand the types of
extensions you are thinking of.
* QUERY_STRING (i.e. extension=param1=fooparam2=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
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
