openstack team mailing list archive

[Loic Dachary <loic@xxxxxxxxxxxx>]

On 05/10/2012 05:54 PM, Doug Hellmann wrote:
>
>
> On Thu, May 10, 2012 at 9:22 AM, Loic Dachary <loic@xxxxxxxxxxxx <mailto: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.
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&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 <mailto:loic@xxxxxxxxxxxx>  ☎ +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@xxxxxxxxxxxxxxxxxxx <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
>     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
// ✉ loic@xxxxxxxxxxxx  ☎ +33 1 49 70 99 82