openstack team mailing list archive

[Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx>]

On Wed, Jul 4, 2012 at 1:52 PM, Nick Barcet <nick.barcet@xxxxxxxxxxxxx>wrote:

> 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.
>

Yes, that is exactly it. Thank you for clarifying what I was trying to say.
:-)


>
> 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 didn't realize that was your intent.


> 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.
>

+1, and thank you for offering to document it.

Doug