openstack team mailing list archive

[Nick Barcet <nick.barcet@xxxxxxxxxxxxx>]

On 07/04/2012 10:55 PM, Julien Danjou wrote:
> On Wed, Jul 04 2012, Nick Barcet wrote:
> 
>> 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.
> 
> So, if I understand you correctly, that would mean the API is non-usable
> for anybody wanting to do fine-grained billing and they would have to
> connect to the database engine directly?
> Because if that's the case I think we miss an abstraction layer
> somewhere.

No, this is not what I am saying. The API offers two types of calls:
 * One which gives access to organized raw events, which rating engines
are likely to be using,
 * One which gives access to summary data, but which are only valid for
simple use cases.
Hopefully, there are no cases here that should justify connecting to the
db engine directly unless one really wants to, and that should not be
recommended as we may want to change our storage model over time without
breaking existing integrations.

The possible variants for describing possible billing strategies are
indeed one abstraction level above this. The telco industry calls the
tool handling this a rating engine (what transforms metering into line
items of a bill) and I intentionally proposed since the beginning that
Ceilometer should not be a rating engine.

We can hope that our current API will be able to evolve to simplify
rating engines requests over time, and we should be ready to accept
extension of it to do so. However I do think we do not have the
necessary experience with rating to propose a universal solution that
will effectively work at this time, and therefore am proposing that we
postpone that until we do have the experience.

Makes sense?
--
Nick Barcet <nick.barcet@xxxxxxxxxxxxx>
aka: nijaba, nicolas

Attachment: signature.asc
Description: OpenPGP digital signature