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 */
signature.asc
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
