Open Stack

Hello!

I was having some chats yesterday with both Julien and Doug regarding some thoughts that occurred to me while digging through CM and Doug suggested that I bring them up on the dev list for everyones benefit and discussion.

My bringing this up is intended to help myself and others get a better understanding of why it's this way, whether we're on the correct course, and, if not, how we get to it. I'm not expecting anything to change quickly or necessarily at all from this. Ultimately the question I'm asking is: are we addressing the correct use cases with the correct API calls; being able to expect certain behavior without having to know the internals? For context, this is mostly using the SQLAlchemy implementation for these questions, but the API questions apply overall.

My concerns:

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

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

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

Thank you all in advance for your time with this. I hope this is productive!

Cheers!

-Thomas













-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130813/f5be255d/attachment.html>