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.d...@hp.com <mailto:dan.d...@hp.com> > > On Wed, May 9, 2012 at 10:44 AM, Nick Barcet <nick.bar...@canonical.com > <mailto:nick.bar...@canonical.com>> wrote: > > > > Doug Hellmann <doug.hellm...@dreamhost.com > <mailto:doug.hellm...@dreamhost.com>> wrote: > > >On Wed, May 9, 2012 at 11:27 AM, Nick Barcet > ><nick.bar...@canonical.com <mailto:nick.bar...@canonical.com>>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@lists.launchpad.net > <mailto:openstack@lists.launchpad.net> > 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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > 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
