Open Stack

Hi,

On Fri, Jul 08, 2016 at 10:39:57AM +0800, 吕冬兵 wrote:
> Hi Stéphane,
> 
> I got what you mean, I’m sure that CloudKitty can rating by event, but
> I have some other puzzles. Let me generally describe the arch of
> Bilean first
> 
> [events] <—> [rating] <—> [billing]
> 
> When event coming from notification, bilean engine will rating the
> resource according policy and rule. A rule reference to a kind of
> resource(instance, volumes e.g), and a policy consists of several
> rules, different user can use different billing policy). After that
> engine will update user’s rate. Bilean doesn’t have period task to do
> billing work, but triggered by events and period task to do health
> check for users (daily task now). When user’s balance is almost used
> up, bilean engine will notify user.
We don't have the same semantics in CloudKitty but it's pretty similar
in the way rating rules processing is done, except that we don't work on
an user basis but tenant/project basis. We want to change this
limitation and enable the cloud admin to apply rating rules on whatever
level he wants. We'll be happy to have you implement this in CloudKitty.
About your health check, we've got an API on top of the storage and a
way to generate report, you can easily get the current total for a
specific user (1 API call). You can implement this with a simple cron
querying the API with the user_id, and checking if the number is past
your set threshold. It's not directly in the code because it's not our
main goal. Plus it's easily done, the amount of code to create a tool
doing this is minimal:

- Load CloudKitty's SDK
- Request total for an user
- Check threshold
- Custom alarming code

> So you see, Bilean is a closed-loop billing solution, what I mean
> trigger-based billing is not just rating by events, the main thing is
> billing. Does CloudKitty do billing too? And how? If not or has
> different solution about that, force to combine them will make it
> neither fish nor fowl.
We don't do billing per se, but we implement a way to crunch OpenStack
data to get sensible numbers (cost). Billing is out of the scope since
it requires knowledge of the local laws, such as VAT, accounting, etc.
There is a lot of billing solutions out there, and most companies
already have one. It looks like you want to do alarming based on
resource consumption, having a cost if enough.

As far as I understand your use case, I don't see why you need to
reimplement components. There is event support in Ceilometer, if you
need to access events directly you can subscribe to them. CloudKitty is
responsible of rating, Gnocchi of metrics storage. The only tricky part
is the alarming one which if I understand correctly is just a matter of
a few lines of Python code. Or even better an Aodh alarm based on
Gnocchi metrics which is the result of CloudKitty's computation.

If I missed or misunderstood something, feel free to correct me.

I would like to find a way to collaborate on this use case without
scattering efforts on similar projects.

Cheers,
Stéphane