Open Stack

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


 
Best regards,
 
lvdongbing

 
 
------------------ Original ------------------
From:  "Stéphan Albert"<sheeprine-ml at nullplace.com>;
Date:  Fri, Jul 8, 2016 05:44 AM
To:  "OpenStack Development Mailing List (not for usage questions)"<openstack-dev at lists.openstack.org>; 

Subject:  Re: [openstack-dev] [Bilean][CloudKitty][Telemetry] Opendiscussionaround Bilean and existing OpenStack components

 
On Thu, Jul 07, 2016 at 09:50:02AM +0800, 吕冬兵 wrote:
> Hi,
> 
> I'm sorry to see this discussion so late:). Thanks for attention.
> 
> I don't oppose to contribute to add trigger-based solution to
> CloudKitty, I just want to know if it's possible to support
> trigger-based for CloudKitty based on now arch, pls generally describe
> how. And another thing I want to make sure is that if it's good to mix
> two different solution in one component.
Hi,

At the moment we have an arch that looks like this

[collector] <-> [orchestrator] <-> [rating, storage, etc]

The orchestrator is responsible of polling data from different backends
using collectors.
We are currently working on a refactor of the internal architecture, we
plan on having rating engines as drivers to ease transitions and
possibility to fully integrate with other engines. And we'll add the "on
demand collect" which is basically a smarter rating engine.
We can easily do something like this:

                   [events]
                      ^
                      |
                      v
[collector] <-> [orchestrator] <-> [rating, storage, etc]

Which is just adding notification handling to the orchestrator. Events
will then be processed by the rating engine.

Everything can be enabled/disabled easily using configuration so that
users can choose what type they need (poll/event). I don't see what can
be the blocking point here.

The new rating engine is on the agenda of next Monday meeting, we can
add a point to talk about collaboration on event based rating.

I'm available if you need any information.

Cheers,
Stéphane

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160708/46e54822/attachment.html>