Mailing List Archive: OpenStack: Dev

[Metering] External API definition

Index | Next | Previous | View Threaded

nick.barcet at canonical

May 8, 2012, 8:27 AM

Post #1 of 14 (247 views)
Permalink

[Metering] External API definition

Hello,

The 3rd meeting of the Ceilometer project will be held on May 10th at
1600 UTC in the #openstack-meeting channel on Freenode. The main subject
we will be tackling this week is the external API definition and I'd
like to gather you opinions on the subject prior to the meeting.

The current proposal which can be found on the blueprint [1] states the
following:

* Database can only be queried via a REST API (i.e. the database schema
is not a supported API and can change in a non backward compatible way
from one version to the other).
* Requests must be authenticated (separate from keystone, or only linked
to accounting type account)
* API Server must be able to be redundant
* Requests allow to
GET account_id list
GET list of counter_type
GET list of events per account
optional start and end for counter_datetime
optional counter_type
GET sum of (counter_volume, counter_duration) for counter_type and
account_id
optional start and end for counter_datetime

Note: the aggregation of values is done by the API and is not stored in
the database. It may be cached for performance reasons but the caching
strategy is outside of the scope of this blueprint.

Any comments, suggestion, etc... are very welcome.

[1] http://wiki.openstack.org/EfficientMetering#API

Thanks a lot,
Nick

Attachments:

signature.asc (0.88 KB)

doug.hellmann at dreamhost

May 8, 2012, 11:39 AM

Post #2 of 14 (236 views)
Permalink

Re: [Metering] External API definition [In reply to]

On Tue, May 8, 2012 at 11:27 AM, Nick Barcet <nick.barcet [at] canonical>wrote:

> Hello,
>
> The 3rd meeting of the Ceilometer project will be held on May 10th at
> 1600 UTC in the #openstack-meeting channel on Freenode. The main subject
> we will be tackling this week is the external API definition and I'd
> like to gather you opinions on the subject prior to the meeting.
>
> The current proposal which can be found on the blueprint [1] states the
> following:
>
> * Database can only be queried via a REST API (i.e. the database schema
> is not a supported API and can change in a non backward compatible way
> from one version to the other).
> * Requests must be authenticated (separate from keystone, or only linked
> to accounting type account)
>

What is the motivation for authenticating with a service other than
keystone?

> * API Server must be able to be redundant
> * Requests allow to
> GET account_id list
> GET list of counter_type
> GET list of events per account
> optional start and end for counter_datetime
> optional counter_type
> GET sum of (counter_volume, counter_duration) for counter_type and
> account_id
> optional start and end for counter_datetime
>
> Note: the aggregation of values is done by the API and is not stored in
> the database. It may be cached for performance reasons but the caching
> strategy is outside of the scope of this blueprint.
>
> Any comments, suggestion, etc... are very welcome.
>
> [1] http://wiki.openstack.org/EfficientMetering#API
>
> Thanks a lot,
> Nick
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>

nick.barcet at canonical

May 8, 2012, 5:43 PM

Post #3 of 14 (231 views)
Permalink

Re: [Metering] External API definition [In reply to]

On 05/08/2012 11:39 AM, Doug Hellmann wrote:
[..]
> * Requests must be authenticated (separate from keystone, or only linked
> to accounting type account)
>
>
> What is the motivation for authenticating with a service other than
> keystone?

The only thing I am trying to express here is that that profiles that
have access to other OpenStack components should not necessarily have
access to metering information. This information should be accessible
only a few select users which group may or may not intersect with users
stored in Keystone already.

Nick

Attachments:

signature.asc (0.88 KB)

nick.barcet at canonical

May 9, 2012, 8:27 AM

Post #4 of 14 (228 views)
Permalink

Re: [Metering] External API definition [In reply to]

On 05/08/2012 08:27 AM, Nick Barcet wrote:
[..]

Thinking about this, I think we need to expend the API a bit to reflect
the evolutions of the schema that we decided last week. Here are my
proposals:

> * Requests allow to
> GET account_id list

change to: GET [user_id|project_id|source] list

> GET list of counter_type
> GET list of events per account
> optional start and end for counter_datetime
> optional counter_type

change to: GET list of events per [user_id|project_id|source]
optional start and end for counter_datetime
optional counter_type

> GET sum of (counter_volume, counter_duration) for counter_type and
> account_id
> optional start and end for counter_datetime

GET sum of (counter_volume, counter_duration) for counter_type and
[user_id|project_id|source]
optional start and end for counter_datetime

Hope this makes sense.

Another item that we need to discuss is extensibility of this API.

Nick

Attachments:

signature.asc (0.88 KB)

doug.hellmann at dreamhost

May 9, 2012, 8:36 AM

Post #5 of 14 (235 views)
Permalink

Re: [Metering] External API definition [In reply to]

On Tue, May 8, 2012 at 8:43 PM, Nick Barcet <nick.barcet [at] canonical>wrote:

> On 05/08/2012 11:39 AM, Doug Hellmann wrote:
> [..]
> > * Requests must be authenticated (separate from keystone, or only
> linked
> > to accounting type account)
> >
> >
> > What is the motivation for authenticating with a service other than
> > keystone?
>
> The only thing I am trying to express here is that that profiles that
> have access to other OpenStack components should not necessarily have
> access to metering information. This information should be accessible
> only a few select users which group may or may not intersect with users
> stored in Keystone already.
>

I see. Is it enough to say that the API is meant for "admin" users only, or
does that still imply more access than we want to grant?

>
> Nick
>
>
>

nick.barcet at canonical

May 9, 2012, 8:48 AM

Post #6 of 14 (231 views)
Permalink

Re: [Metering] External API definition [In reply to]

On 05/09/2012 08:36 AM, Doug Hellmann wrote:
>
>
> On Tue, May 8, 2012 at 8:43 PM, Nick Barcet <nick.barcet [at] canonical
> <mailto:nick.barcet [at] canonical>> wrote:
>
> On 05/08/2012 11:39 AM, Doug Hellmann wrote:
> [..]
> > * Requests must be authenticated (separate from keystone, or
> only linked
> > to accounting type account)
> >
> >
> > What is the motivation for authenticating with a service other than
> > keystone?
>
> The only thing I am trying to express here is that that profiles that
> have access to other OpenStack components should not necessarily have
> access to metering information. This information should be accessible
> only a few select users which group may or may not intersect with users
> stored in Keystone already.
>
>
> I see. Is it enough to say that the API is meant for "admin" users only,
> or does that still imply more access than we want to grant?

I don't see the point to try to restrict admins from this, as it would
be mostly pointless in the end, but I do see the need to define a type
of account which only right is to consult this information without any
other privilege.

Nick

Attachments:

signature.asc (0.88 KB)

doug.hellmann at dreamhost

May 9, 2012, 8:59 AM

Post #7 of 14 (231 views)
Permalink

Re: [Metering] External API definition [In reply to]

On Wed, May 9, 2012 at 11:27 AM, Nick Barcet <nick.barcet [at] canonical>wrote:

> On 05/08/2012 08:27 AM, Nick Barcet wrote:
> [..]
>
> Thinking about this, I think we need to expend the API a bit to reflect
> the evolutions of the schema that we decided last week. Here are my
> proposals:
>
> > * Requests allow to
> > GET account_id list
>
> change to: GET [user_id|project_id|source] list
>

Does the [value|value] syntax mean "choose one" or "combine"? I assume
"choose one" and you are using square brackets because parens are used in
some of the other queries.

>
> > GET list of counter_type
> > GET list of events per account
> > optional start and end for counter_datetime
> > optional counter_type
>
> change to: GET list of events per [user_id|project_id|source]
> optional start and end for counter_datetime
> optional counter_type
>

Users may cross projects, so I'm not sure it makes sense to ask for the
events generated by a user without restricting it by the project. At the
very least we may need to allow them to specify user_id or project_id or
both.

>
> > GET sum of (counter_volume, counter_duration) for counter_type and
> > account_id
> > optional start and end for counter_datetime
>
> GET sum of (counter_volume, counter_duration) for counter_type and
> [user_id|project_id|source]
> optional start and end for counter_datetime
>
> Hope this makes sense.
>
> Another item that we need to discuss is extensibility of this API.
>
> Nick
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>

nick.barcet at canonical

May 9, 2012, 9:44 AM

Post #8 of 14 (224 views)
Permalink

Re: [Metering] External API definition [In reply to]

Doug Hellmann <doug.hellmann [at] dreamhost> wrote:

>On Wed, May 9, 2012 at 11:27 AM, Nick Barcet
><nick.barcet [at] canonical>wrote:
>
>> On 05/08/2012 08:27 AM, Nick Barcet wrote:
>> [..]
>>
>> Thinking about this, I think we need to expend the API a bit to
>reflect
>> the evolutions of the schema that we decided last week. Here are my
>> proposals:
>>
>> > * Requests allow to
>> > GET account_id list
>>
>> change to: GET [user_id|project_id|source] list
>>
>
>Does the [value|value] syntax mean "choose one" or "combine"? I assume
>"choose one" and you are using square brackets because parens are used
>in some of the other queries.

You assumed correctly :)

>>
>> > GET list of counter_type
>> > GET list of events per account
>> > optional start and end for counter_datetime
>> > optional counter_type
>>
>> change to: GET list of events per [user_id|project_id|source]
>> optional start and end for counter_datetime
>> optional counter_type
>>
>
>Users may cross projects, so I'm not sure it makes sense to ask for the
>events generated by a user without restricting it by the project. At
>the very least we may need to allow them to specify user_id or project_id
>or both.

Good point. Thanks for catching this.

>>
>> > GET sum of (counter_volume, counter_duration) for counter_type
>and
>> > account_id
>> > optional start and end for counter_datetime
>>
>> GET sum of (counter_volume, counter_duration) for counter_type and
>> [user_id|project_id|source]
>> optional start and end for counter_datetime
>>
>> Hope this makes sense.
>>
>> Another item that we need to discuss is extensibility of this API.
>>
>> Nick

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

dan.dyer00 at gmail

May 9, 2012, 8:46 PM

Post #9 of 14 (224 views)
Permalink

Re: [Metering] External API definition [In reply to]

Is it your assumption that there will be one metering service per
"installation" or one per service (i.e swift, nova)? My assumption would be
a single metering service, so the API would need to handle some additional
use cases:
-list services supported
-list metrics for a service type
-get metric details

I would also consider separate use cases for accessing raw events vs.
aggregated metrics.

Dan Dyer
dan.dyer [at] hp

On Wed, May 9, 2012 at 10:44 AM, Nick Barcet <nick.barcet [at] canonical>wrote:

>
>
> Doug Hellmann <doug.hellmann [at] dreamhost> wrote:
>
> >On Wed, May 9, 2012 at 11:27 AM, Nick Barcet
> ><nick.barcet [at] canonical>wrote:
> >
> >> On 05/08/2012 08:27 AM, Nick Barcet wrote:
> >> [..]
> >>
> >> Thinking about this, I think we need to expend the API a bit to
> >reflect
> >> the evolutions of the schema that we decided last week. Here are my
> >> proposals:
> >>
> >> > * Requests allow to
> >> > GET account_id list
> >>
> >> change to: GET [user_id|project_id|source] list
> >>
> >
> >Does the [value|value] syntax mean "choose one" or "combine"? I assume
> >"choose one" and you are using square brackets because parens are used
> >in some of the other queries.
>
> You assumed correctly :)
>
> >>
> >> > GET list of counter_type
> >> > GET list of events per account
> >> > optional start and end for counter_datetime
> >> > optional counter_type
> >>
> >> change to: GET list of events per [user_id|project_id|source]
> >> optional start and end for counter_datetime
> >> optional counter_type
> >>
> >
> >Users may cross projects, so I'm not sure it makes sense to ask for the
> >events generated by a user without restricting it by the project. At
> >the very least we may need to allow them to specify user_id or project_id
> >or both.
>
> Good point. Thanks for catching this.
>
> >>
> >> > GET sum of (counter_volume, counter_duration) for counter_type
> >and
> >> > account_id
> >> > optional start and end for counter_datetime
> >>
> >> GET sum of (counter_volume, counter_duration) for counter_type and
> >> [user_id|project_id|source]
> >> optional start and end for counter_datetime
> >>
> >> Hope this makes sense.
> >>
> >> Another item that we need to discuss is extensibility of this API.
> >>
> >> Nick
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>

loic at enovance

May 10, 2012, 2:09 AM

Post #10 of 14 (231 views)
Permalink

Re: [Metering] External API definition [In reply to]

On 05/10/2012 05:46 AM, Daniel Dyer wrote:
> Is it your assumption that there will be one metering service per "installation" or one per service (i.e swift, nova)? My assumption would be a single metering service, so the API would need to handle some additional use cases:
> -list services supported
> -list metrics for a service type
> -get metric details
>
Hi,

I added the "list services supported" assuming service == OpenStack component (nova, swift etc.)

http://wiki.openstack.org/EfficientMetering?action=diff&rev2=66&rev1=65

I added the "list meters for a component"

http://wiki.openstack.org/EfficientMetering?action=diff&rev2=67&rev1=66

I'm not sure what you mean by "metric details", could you expand ? It could be a description (human readable ?) of a given meter. Since we're using a fixed form storage, I'm not sure what else needs to be returned.

Cheers
> I would also consider separate use cases for accessing raw events vs. aggregated metrics.
>
> Dan Dyer
> dan.dyer [at] hp <mailto:dan.dyer [at] hp>
>
> On Wed, May 9, 2012 at 10:44 AM, Nick Barcet <nick.barcet [at] canonical <mailto:nick.barcet [at] canonical>> wrote:
>
>
>
> Doug Hellmann <doug.hellmann [at] dreamhost <mailto:doug.hellmann [at] dreamhost>> wrote:
>
> >On Wed, May 9, 2012 at 11:27 AM, Nick Barcet
> ><nick.barcet [at] canonical <mailto:nick.barcet [at] canonical>>wrote:
> >
> >> On 05/08/2012 08:27 AM, Nick Barcet wrote:
> >> [..]
> >>
> >> Thinking about this, I think we need to expend the API a bit to
> >reflect
> >> the evolutions of the schema that we decided last week. Here are my
> >> proposals:
> >>
> >> > * Requests allow to
> >> > GET account_id list
> >>
> >> change to: GET [user_id|project_id|source] list
> >>
> >
> >Does the [value|value] syntax mean "choose one" or "combine"? I assume
> >"choose one" and you are using square brackets because parens are used
> >in some of the other queries.
>
> You assumed correctly :)
>
> >>
> >> > GET list of counter_type
> >> > GET list of events per account
> >> > optional start and end for counter_datetime
> >> > optional counter_type
> >>
> >> change to: GET list of events per [user_id|project_id|source]
> >> optional start and end for counter_datetime
> >> optional counter_type
> >>
> >
> >Users may cross projects, so I'm not sure it makes sense to ask for the
> >events generated by a user without restricting it by the project. At
> >the very least we may need to allow them to specify user_id or project_id
> >or both.
>
> Good point. Thanks for catching this.
>
> >>
> >> > GET sum of (counter_volume, counter_duration) for counter_type
> >and
> >> > account_id
> >> > optional start and end for counter_datetime
> >>
> >> GET sum of (counter_volume, counter_duration) for counter_type and
> >> [user_id|project_id|source]
> >> optional start and end for counter_datetime
> >>
> >> Hope this makes sense.
> >>
> >> Another item that we need to discuss is extensibility of this API.
> >>
> >> Nick
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack <https://launchpad.net/%7Eopenstack>
> Post to : openstack [at] lists <mailto:openstack [at] lists>
> Unsubscribe : https://launchpad.net/~openstack <https://launchpad.net/%7Eopenstack>
> More help : https://help.launchpad.net/ListHelp
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp

--
Lo�c Dachary Chief Research Officer
// eNovance labs http://labs.enovance.com
// ? loic [at] enovance ? +33 1 49 70 99 82

loic at enovance

May 10, 2012, 6:22 AM

Post #11 of 14 (225 views)
Permalink

Re: [Metering] API Extensibility (was: External API definition) [In reply to]

> 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:

* 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 [at] enovance ☎ +33 1 49 70 99 82

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

nick.barcet at canonical

May 10, 2012, 7:29 AM

Post #12 of 14 (226 views)
Permalink

Re: [Metering] API Extensibility (was: External API definition) [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Loic Dachary <loic [at] enovance> 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:
>
>* 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

I like this approach and the possibilities it provides. It will introduce some interesting questions for caching implementation, but we hound not worry about that yet, I think.

- --
Nick Barcet <nick.barcet [at] canonical>
aka: nicolas, nijaba
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.8

iGsEAREIACsFAk+r0LkkHE5pY29sYXMgQmFyY2V0IDxuaWNvbGFzQGJhcmNldC5j
b20+AAoJEFiD3l2iIpt4/zQAmQEqxPvRVlTpndcwNwhl0SeHq9i8AKCXMsGcPI0g
NNaIx8a+3rwi2Dlaeg==
=WkXC
-----END PGP SIGNATURE-----

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

nick.barcet at canonical

May 10, 2012, 7:39 AM

Post #13 of 14 (221 views)
Permalink

Re: [Metering] External API definition [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Daniel Dyer <dan.dyer00 [at] gmail> wrote: One per installation, at least, since the source field could allow to aggregate informations from multiple installations.

>Is it your assumption that there will be one metering service per
>"installation" or one per service (i.e swift, nova)? My assumption
>would be
>a single metering service, so the API would need to handle some
>additional
>use cases:
>-list services supported
>-list metrics for a service type
>-get metric details

One per installation, at least, since the source field could allow to aggregate information from multiple installations. Can't See any reason why not to offer what you list above, even though one may deduce the component from the counter name.

>I would also consider separate use cases for accessing raw events vs.
>aggregated metrics.

I think the extension proposal from Loic would cover that and more.

>Dan Dyer
>dan.dyer [at] hp
>
>On Wed, May 9, 2012 at 10:44 AM, Nick Barcet
><nick.barcet [at] canonical>wrote:
>
>>
>>
>> Doug Hellmann <doug.hellmann [at] dreamhost> wrote:
>>
>> >On Wed, May 9, 2012 at 11:27 AM, Nick Barcet
>> ><nick.barcet [at] canonical>wrote:
>> >
>> >> On 05/08/2012 08:27 AM, Nick Barcet wrote:
>> >> [..]
>> >>
>> >> Thinking about this, I think we need to expend the API a bit to
>> >reflect
>> >> the evolutions of the schema that we decided last week. Here are
>my
>> >> proposals:
>> >>
>> >> > * Requests allow to
>> >> > GET account_id list
>> >>
>> >> change to: GET [user_id|project_id|source] list
>> >>
>> >
>> >Does the [value|value] syntax mean "choose one" or "combine"? I
>assume
>> >"choose one" and you are using square brackets because parens are
>used
>> >in some of the other queries.
>>
>> You assumed correctly :)
>>
>> >>
>> >> > GET list of counter_type
>> >> > GET list of events per account
>> >> > optional start and end for counter_datetime
>> >> > optional counter_type
>> >>
>> >> change to: GET list of events per [user_id|project_id|source]
>> >> optional start and end for counter_datetime
>> >> optional counter_type
>> >>
>> >
>> >Users may cross projects, so I'm not sure it makes sense to ask for
>the
>> >events generated by a user without restricting it by the project. At
>> >the very least we may need to allow them to specify user_id or
>project_id
>> >or both.
>>
>> Good point. Thanks for catching this.
>>
>> >>
>> >> > GET sum of (counter_volume, counter_duration) for counter_type
>> >and
>> >> > account_id
>> >> > optional start and end for counter_datetime
>> >>
>> >> GET sum of (counter_volume, counter_duration) for counter_type
>and
>> >> [user_id|project_id|source]
>> >> optional start and end for counter_datetime
>> >>
>> >> Hope this makes sense.
>> >>
>> >> Another item that we need to discuss is extensibility of this API.
>> >>
>> >> Nick
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack [at] lists
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>

- --
Nick Barcet <nick.barcet [at] canonical>
aka: nicolas, nijaba
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.8

iGsEAREIACsFAk+r0yYkHE5pY29sYXMgQmFyY2V0IDxuaWNvbGFzQGJhcmNldC5j
b20+AAoJEFiD3l2iIpt4+w0AmgIBEBQUXHAeOiTko3X5lYcGjqi4AKCQcUC9DyPe
FBhL9NxeTMtAv1xsJg==
=7Udb
-----END PGP SIGNATURE-----

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

doug.hellmann at dreamhost

May 10, 2012, 8:54 AM

Post #14 of 14 (224 views)
Permalink

Re: [Metering] API Extensibility (was: External API definition) [In reply to]

On Thu, May 10, 2012 at 9:22 AM, Loic Dachary <loic [at] enovance> 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 [at] enovance ☎ +33 1 49 70 99 82
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads