<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 13, 2013 at 2:36 PM, Thomas Maddox <span dir="ltr"><<a href="mailto:thomas.maddox@rackspace.com" target="_blank">thomas.maddox@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">



<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>Hello!</div>
<div><br>
</div>
<div>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. </div>

<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>My concerns:</div>
<ul>
<li>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
<b>getting a list of resources a user had during a period of time to get meters to compute billing with</b>. The semantics are tripping me up a bit; the question this boiled down to for me was:
<u>why use a resource query to get meters to show usage by a tenant</u>? 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.<span style="font-family:arial;font-size:small"> </span></li></ul></div></blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<ul><li>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.</li></ul></div></blockquote><div>
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. </div>
<div><br></div><div>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).</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<ul><li>This brought up some confusion with the API for me with the major use cases I can think of:
<ul>
<li>As a new consumer of this API, I would think that <b>/resource/<resource_id></b> 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</li></ul></li></ul></div></blockquote><div>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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"><ul><li><ul><li>I would think that <b>/meter/?q.field=resource_id&q.value=<resource_id></b> 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.</li>
</ul></li></ul></div></blockquote><div>The meters associated with a resource are provided as part of the response to the resources query, so no separate call is needed.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"><ul><li><ul><li>
<ul>
<li>Additionally <b>/meter/?q.field=user_id&q.value=<user_id></b> would get me a list of all meters that are currently related to the user</li></ul></li></ul></li></ul></div></blockquote><div>Yes, we're in the process of replacing the term "meter" with "sample." Bad choice of name that will require a deprecation period.</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<ul><li><ul><li>
</li><li>The ultimate use case, for billing queries, I would think that <b>/meter/<meter_id>/statistics?<time filters>&<user>&(<resource_id>)</b> would get me the measurements for that meter to bill for.</li>
</ul></li></ul></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<ul><li>
</li></ul>
<div>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: <a href="https://blueprints.launchpad.net/ceilometer/+spec/api-group-by" target="_blank">https://blueprints.launchpad.net/ceilometer/+spec/api-group-by</a>).</div>

<div><br>
</div>
<div>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. =]</div>
<div><br>
</div>
<div>Thank you all in advance for your time with this. I hope this is productive!</div>
<div><br>
</div>
<div>Cheers!</div><span class=""><font color="#888888">
<div><br>
</div>
<div>-Thomas</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</font></span></div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>