[openstack-dev] [Ceilometer] Concerning get_resources/get_meters and the Ceilometer API
julien at danjou.info
Wed Aug 14 09:17:21 UTC 2013
On Tue, Aug 13 2013, Thomas Maddox wrote:
> * 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
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
> 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:
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!
/* Free Software hacker * freelance consultant
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 835 bytes
Desc: not available
More information about the OpenStack-dev