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
