Open Stack

The heart of nova-biling is built around accounts, resources, billing segments with a tariff and cost.  Not clear at my first review where/how these costs are set.

Brian

-------------------------------------------------
Brian Schott, CTO
Nimbis Services, Inc.
brian.schott at nimbisservices.com
ph: 443-274-6064  fx: 443-274-6060



On Apr 22, 2012, at 5:38 PM, Luis Gervaso wrote:

> I see this is an accounting system, a billing system needs things like promotional codes, vat, invoices ...
> 
> I'm proposing the way the events should be orchestated
> 
> Please, correct me, if i'm wrong
> 
> Luis
> 
> On Sun, Apr 22, 2012 at 11:16 PM, Atul Jha <Atul.Jha at csscorp.com> wrote:
> Hi,
> Has anyone checked this http://www.griddynamics.com/openstack/docs/nova-billing/quickstart.html
> ________________________________________
> From: openstack-bounces+atul.jha=csscorp.com at lists.launchpad.net [openstack-bounces+atul.jha=csscorp.com at lists.launchpad.net] on behalf of Endre Karlson [endre.karlson at gmail.com]
> Sent: Monday, April 23, 2012 2:27 AM
> To: openstack at lists.launchpad.net
> Subject: Re: [Openstack] Monitoring / Billing Architecture proposed
> 
> What is Dough then compared to what you want to do ?
> 
> 2012/4/22 Endre Karlson <endre.karlson at gmail.com<mailto:endre.karlson at gmail.com>>
> What is Dough then ?
> 
> 
> 2012/4/22 Brian Schott <brian.schott at nimbisservices.com<mailto:brian.schott at nimbisservices.com>>
> I see this blueprint for metering, but none for Dough currently.
> http://wiki.openstack.org/EfficientMetering
> 
> Here are the Dough slides, however:
> http://www.slideshare.net/lzyeval/dough-openstack-billing-project
> 
> We collectively need to talk more about the user scenarios, because I don't think you can just put a decorator around the API rpc calls and get an accurate picture of what to bill for later.  There are metered things like bandwidth or IOPS, events that happen outside of the API (shutdown -h), and it is hard to predict what a reseller will want to charge for.  It is better to put a metering system in that can handle many billing configurations.
> 
> 
> -------------------------------------------------
> Brian Schott, CTO
> Nimbis Services, Inc.
> brian.schott at nimbisservices.com<mailto:brian.schott at nimbisservices.com>
> ph: 443-274-6064<tel:443-274-6064>  fx: 443-274-6060<tel:443-274-6060>
> 
> 
> 
> On Apr 22, 2012, at 3:36 PM, Luis Gervaso wrote:
> 
> Dough is the proposed billing platform/product (where the billing rules live), isn't it?
> 
> I don't know Dough enough, so please me correct me if i'm wrong.
> 
> I'm trying to define a generic/agnostic integration process, obviously where Dough
> can fit perfectly. I would like it become part to the reference architecture.
> 
> Option 1) [3b in the arch proposed]
> 
> Dough should pull NoSQL
> 
> Option 2)
> 
> A Mediator can feed Dough
> 
> 
> On Sun, Apr 22, 2012 at 9:13 PM, Endre Karlson <endre.karlson at gmail.com<mailto:endre.karlson at gmail.com>> wrote:
> What about using the Dough project?
> 
> Endre.
> 
> 
> 2012/4/22 Endre Karlson <endre.karlson at gmail.com<mailto:endre.karlson at gmail.com>>
> What about using the Dough project ?
> 
> Endre.
> 
> 2012/4/22 Luis Gervaso <luis at woorea.es<mailto:luis at woorea.es>>
> Hi,
> 
> I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support:
> 
> 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel)
> 
> 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion)
> 
> 3a. The monitoring system can pull/push MongoDB
> 
> 3b. The billing system can pull to create invoices
> 
> 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel)
> 
> This is to receive your feedback. So please, critics are welcome!
> 
> Cheers!
> 
> --
> -------------------------------------------
> Luis Alberto Gervaso Martin
> Woorea Solutions, S.L
> CEO & CTO
> mobile: (+34) 627983344<tel:%28%2B34%29%20627983344>
> luis@<mailto:luis.gervaso at gmail.com>woorea.es<http://woorea.es/>
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
> --
> -------------------------------------------
> Luis Alberto Gervaso Martin
> Woorea Solutions, S.L
> CEO & CTO
> mobile: (+34) 627983344<tel:%28%2B34%29%20627983344>
> luis@<mailto:luis.gervaso at gmail.com>woorea.es<http://woorea.es/>
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> http://www.csscorp.com/common/email-disclaimer.php
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> -- 
> -------------------------------------------
> Luis Alberto Gervaso Martin
> Woorea Solutions, S.L
> CEO & CTO
> mobile: (+34) 627983344
> luis at woorea.es
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120422/8444983d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3662 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120422/8444983d/attachment.bin>