openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #11504
Re: [Metering] External API definition
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@xxxxxx
On Wed, May 9, 2012 at 10:44 AM, Nick Barcet <nick.barcet@xxxxxxxxxxxxx>wrote:
>
>
> Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx> wrote:
>
> >On Wed, May 9, 2012 at 11:27 AM, Nick Barcet
> ><nick.barcet@xxxxxxxxxxxxx>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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
Follow ups
References