openstack team mailing list archive

[Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx>]

On Thu, May 10, 2012 at 9:22 AM, Loic Dachary <loic@xxxxxxxxxxxx> 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&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:
>

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=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
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>