<br><br><div class="gmail_quote">On Wed, Jul 4, 2012 at 1:52 PM, Nick Barcet <span dir="ltr"><<a href="mailto:nick.barcet@canonical.com" target="_blank">nick.barcet@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 06/29/2012 03:04 PM, Doug Hellmann wrote:<br>
[..]<br>
<div class="im">> My conclusion from all of this (over-)thinking is that the ceilometer<br>
> API should assume the simple case and ignore the metadata changes when<br>
> computing the sum or maximum value for a counter over a range of time.<br>
> More complex processing will be left up to the caller, who can ask for<br>
> raw metering data in manageable chunks and process them outside of the<br>
> API. I could be persuaded to do something more complicated if the<br>
> problems described above can be solved in a relatively simple way, but<br>
> even then I think we should push that to the v2 API.<br>
</div>[..]<br>
<br>
Sorry for my late reply on this, but...<br>
<br>
So, if I summarize what you are saying, the problem is that for a given<br>
Instance ID, a given meter may have to be interpreted as if the Instance<br>
ID was changing over time.<br>
<br>
Example:<br>
t1: Instance A - Has 1 CPU - 64G ram - runs in zone 1<br>
t2: Instance A - Has 2 CPU - 64G ram - runs in zone 1<br>
t3: Instance A - Has 2 CPU - 128G ram - runs in zone 1<br>
t4: Instance A - Has 2 CPU - 128G ram - runs in zone 3<br>
t5: Instance A is stopped<br>
<br>
>From a billing point of view, what is important here is that even though<br>
the Instance ID remains the same, we have in fact 4 different segments<br>
of time which could lead to 4 different pricing being applied to the<br>
same instance:<br>
<br>
t1->t2: price 1<br>
t2->t3: price 2<br>
t3->t4: price 3<br>
t4->t5: price 4<br>
<br>
So we need to be able to inform the rating engine that these events have<br>
occurred so that it does not uniformly apply a billing price to from a<br>
sum of a given meter volume.  But in fact this information is indeed<br>
captured and accessible to rating engines via their respective meters.<br></blockquote><div><br></div><div>Yes, that is exactly it. Thank you for clarifying what I was trying to say. :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
What is interesting here is that, in my mind, the sum and duration<br>
function of the API, when I proposed it, were only meant to be able to:<br>
 * In a simple amazon type billing model where instances cannot change<br>
zone, add CPU or add ram,<br>
 * In a Private cloud scenario where you only need simple usage stats to<br>
inform your users,<br>
 * in a horizon plugin to give a quick summary of use,<br>
and would never be used by any serious rating engines that would in each<br>
and every case require to have access to the raw list of events so that<br>
it can recreate the full time line of the events.  This is where we need<br>
to draw the line between metering and rating.<br></blockquote><div><br></div><div>I didn't realize that was your intent. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I therefore propose that we leave the API as is, knowing the side<br>
effects of such high level sum and duration calculations. If we agree on<br>
this, I take the action to document the limitation of the summary<br>
functions of the API.<br></blockquote><div><br></div><div>+1, and thank you for offering to document it.</div><div><br></div><div>Doug </div></div>