Open Stack

On 8/14/13 7:48 AM, "Sandy Walsh" <sandy.walsh at RACKSPACE.COM> wrote:

>
>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". :)

Yep; sorry this ended up in two emails, hehe.

>> 
>>>   *   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

Am I misunderstanding the code? This looks like it's returning the first
sample's details: 
https://github.com/openstack/ceilometer/blob/master/ceilometer/storage/impl
_mongodb.py#L578-L584. When I change the metadata attribute's aggregation
function from $first to $last, I get the latest state of the resource,
which corrects the bug I'm working on. Otherwise, a newly built instance
sits in a 'scheduling' state, according to the API call
(https://bugs.launchpad.net/ceilometer/+bug/1208547).


>> 
>> 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.

That's definitely a good point; I didn't know that. I suppose if we wanted
to make this API change, it'd have to be 'who owns it currently' as part
of the contract for what details are returned. The event body or samples
can give the historical details when desired. From a billing perspective,
it'd be good to know ownership over time in order to bill appropriately
for binary ownership billing rather than usage. Hmmmm...


>> 
>>>      *   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.

Awesome! Thanks for the great responses. I didn't see that BP. I'll add to
it once I get these ideas fleshed out more. =]

-Thomas

>
>
>> 
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>