On Wed, Jul 4, 2012 at 1:52 PM, Nick Barcet <nick.bar...@canonical.com>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
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp