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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
