Open Stack

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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>