Open Stack

On Tue, Aug 13 2013, Thomas Maddox wrote:

Hi Thomas,

>   *   Driving get_resources() with the Meter table instead of the
>   Resource table. This is mainly because of the additional filtering
>   available in the Meter table, which allows us to satisfy a use case
>   like getting a list of resources a user had during a period of time
>   to get meters to compute billing with. The semantics are tripping me
>   up a bit; the question this boiled down to for me was: why use a
>   resource query to get meters to show usage by a tenant? I was
>   curious about why we needed the timestamp filtering when looking at
>   Resources, and why we would use Resource as a way to get at metering
>   data, rather than a Meter request itself? This was answered by
>   resources being the current vector to get at metering data for a
>   tenant in terms of resources, if I understood correctly.
>   *   With this implementation, we have to do aggregation to get at
>   the discrete Resources (via the Meter table) rather than just
>   filtering the already distinct ones in the Resource table.

I think I already answered that in a previous email when I said "drop
the resource table". :)

>   *   This brought up some confusion with the API for me with the
>   major use cases I can think of:
>      *   As a new consumer of this API, I would think that
>   /resource/<resource_id> would get me details for a resource, e.g.
>   current state, when it was created, last updated/used timestamp, who
>   owns it; not the attributes from the first sample to come through
>   about it

s/first/last/ actually

I wouldn't disagree if you had such improvements to propose.
However, we're pretty flexible in Ceilometer as we don't allow only
metering OpenStack; be careful of somethings like "who owns it" might
change in other systems than OpenStack for example, depending on the
time range you filter on.

>      *   I would think that
>      /meter/?q.field=resource_id&q.value=<resource_id> ought to get me
>      a list of meter(s) details for a specific resource, e.g. name,
>      unit, and origin; but not a huge mixture of samples.

That could be a nice improvement indeed.

>         *   Additionally /meter/?q.field=user_id&q.value=<user_id>
>         would get me a list of all meters that are currently related
>         to the user

Same as above.

>      *   The ultimate use case, for billing queries, I would think
>      that /meter/<meter_id>/statistics?<time
>      filters>&<user>&(<resource_id>) would get me the measurements for
>      that meter to bill for.

We'd like that too, though it's not always perfect since we don't handle
the different counter types explicitly.

> If I understand correctly, one main intent driving this is wanting to
> avoid end users having to write a bunch of API requests themselves
> from the billing side and instead just drill down from payloads for
> each resource to get the billing information for their customers. It
> also looks like there's a BP to add grouping functionality to
> statistics queries to allow us this functionality easily (this one, I
> think:
> https://blueprints.launchpad.net/ceilometer/+spec/api-group-by).

Yes.

> I'm new to this project, so I'm trying to get a handle on how we got
> here and maybe offer some outside perspective, if it's needed or
> wanted. =]

I think you got the picture right. We're trying to improve the API, but
we always happy to get help. There's a sort of meta blueprint:

  https://blueprints.launchpad.net/ceilometer/+spec/api-v2-improvement

With various ideas to improve the API. It's assigned to me, though I
didn't implement most of the ideas there, and won't probably have time
to implement them all, so feel free to contribute!

-- 
Julien Danjou
/* Free Software hacker * freelance consultant
   http://julien.danjou.info */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130814/25ef3266/attachment.pgp>