On 05/10/2012 05:54 PM, Doug Hellmann wrote: > > > On Thu, May 10, 2012 at 9:22 AM, Loic Dachary <l...@enovance.com > <mailto: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=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: > > > 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. I agree. > > 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. > No specific reason, we can just forget about it. I'm grateful jaypipes suggested it during the last meeting, that will save us time.
Cheers > > > * 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 <mailto:l...@enovance.com> ☎ +33 1 49 70 99 82 > <tel:%2B33%201%2049%2070%2099%2082> > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > <https://launchpad.net/%7Eopenstack> > Post to : openstack@lists.launchpad.net > <mailto:openstack@lists.launchpad.net> > Unsubscribe : https://launchpad.net/~openstack > <https://launchpad.net/%7Eopenstack> > More help : https://help.launchpad.net/ListHelp > > -- 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