On 08/14/2013 06:17 AM, Julien Danjou wrote: > 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! >
+1 ... I think that would clear up a lot of confusion not only in the api, but the underlying db & models. > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
