Re: [openstack-dev] [Bilean][CloudKitty][Telemetry] Opendiscussionaround Bilean and existing OpenStack components
On Fri, Jul 08 2016, Stéphane Albert wrote: > 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 It'd be interesting to use Aodh to do that. :) -- Julien Danjou # Free Software hacker # https://julien.danjou.info signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Bilean][CloudKitty][Telemetry] Opendiscussionaround Bilean and existing OpenStack components
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 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Bilean][CloudKitty][Telemetry] Opendiscussionaround Bilean and existing OpenStack components
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...@nullplace.com>; Date: Fri, Jul 8, 2016 05:44 AM To: "OpenStack Development Mailing List (not for usage questions)"<openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
