Open Stack

On 06/29/2012 03:04 PM, Doug Hellmann wrote:
[..]
> My conclusion from all of this (over-)thinking is that the ceilometer
> API should assume the simple case and ignore the metadata changes when
> computing the sum or maximum value for a counter over a range of time.
> More complex processing will be left up to the caller, who can ask for
> raw metering data in manageable chunks and process them outside of the
> API. I could be persuaded to do something more complicated if the
> problems described above can be solved in a relatively simple way, but
> even then I think we should push that to the v2 API.
[..]

Sorry for my late reply on this, but...

So, if I summarize what you are saying, the problem is that for a given
Instance ID, a given meter may have to be interpreted as if the Instance
ID was changing over time.

Example:
t1: Instance A - Has 1 CPU - 64G ram - runs in zone 1
t2: Instance A - Has 2 CPU - 64G ram - runs in zone 1
t3: Instance A - Has 2 CPU - 128G ram - runs in zone 1
t4: Instance A - Has 2 CPU - 128G ram - runs in zone 3
t5: Instance A is stopped

From a billing point of view, what is important here is that even though
the Instance ID remains the same, we have in fact 4 different segments
of time which could lead to 4 different pricing being applied to the
same instance:

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.

Nick




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120704/578c1812/attachment.sig>