Open Stack

On Tue, Aug 13, 2013 at 2:36 PM, Thomas Maddox
<thomas.maddox at rackspace.com>wrote:

>  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.
>
> Querying first for resources and then getting the statistics is an
artifact of the design of the V1 API, where both the resource id and meter
name were part of the statistics API URL. After the groupby feature lands
in the V2 statistics API, we won't have to make the separate query any more
to satisfy the billing requirement.

However, that's just one example use case. Sometimes people do want to know
something about the resources that have existed besides the aggregated
samples for billing. The challenge with querying for resources is that the
metadata for a given resource has the potential to change over time. The
resource table holds the most current metadata, but the meter table has all
of the samples and all of the versions of the metadata, so we have to look
there to filter on metadata that might change (especially if we're trying
to answer questions about what resources had specific characteristics
during a time range).

>
>    - 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
>
> It should be returning the attributes for the *last* sample to be seen, so
that the metadata and other settings are the most recent values.

>
>    -
>       - 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.
>
> The meters associated with a resource are provided as part of the response
to the resources query, so no separate call is needed.

>
>    -
>       -
>          - 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
>
> Yes, we're in the process of replacing the term "meter" with "sample." Bad
choice of name that will require a deprecation period.

>
>    -
>       -
>       - 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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130816/bc86af36/attachment.html>