t1->t2: price 1
t2->t3: price 2
t3->t4: price 3
t4->t5: price 4
So we need to be able to inform the rating engine that these events have
occurred so that it does not uniformly apply a billing price to from a
sum of a given meter volume. But in fact this information is indeed
captured and accessible to rating engines via their respective meters.
What is interesting here is that, in my mind, the sum and duration
function of the API, when I proposed it, were only meant to be able to:
* In a simple amazon type billing model where instances cannot change
zone, add CPU or add ram,
* In a Private cloud scenario where you only need simple usage stats to
inform your users,
* in a horizon plugin to give a quick summary of use,
and would never be used by any serious rating engines that would in each
and every case require to have access to the raw list of events so that
it can recreate the full time line of the events. This is where we need
to draw the line between metering and rating.
I therefore propose that we leave the API as is, knowing the side
effects of such high level sum and duration calculations. If we agree on
this, I take the action to document the limitation of the summary
functions of the API.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 900 bytes
Desc: OpenPGP digital signature