Hi, I'm the person who presented Dough. After my presentation there were lots of feedback from many people.
The conclusion was that no matter how generic I tried to design Dough, the billing requirements of each company will vary if they have different metering specifications. Therefore a few companies have agreed to first work on a metering system together as described in http://wiki.openstack.org/EfficientMetering and http://etherpad.openstack.org/EfficientMetering They plan to officially launch a metering project and incubate the project in Folsom if possible. What I plan to do with Dough is to first use it in production and present how it worked out in our beta service at the next summit. Kanyun will be replaced with the new metering system. I'll work on the documentation of Dough once I finish testing it with our closed beta production environment. Cheers, LZY On Sun, Apr 22, 2012 at 5:43 PM, Luis Gervaso <[email protected]> wrote: > > > On Mon, Apr 23, 2012 at 2:10 AM, Brian Schott < > [email protected]> wrote: > >> Agreed. Not to mention all of those web commerce systems (Ubercart, >> Sachmo, Mezzanine/Cartridge, and many wordpress and rails commerce >> platforms I don't know). We don't need to reinvent selling stuff on the >> Internet. So, what's really missing? >> >> 1) The ability to query historical cloud resource utilization over a >> given time period for usage reports, graphs, and invoice generation. The >> alternative is polling the status interfaces frequently and caching >> externally. Many applications could use this with no need of billing >> semantics. Horizon can show you current instances, volumes, cores, memory, >> disk, etc. but no way it could give you a graph over time given that it >> doesn't store any historical data. It shouldn't store historical data, >> another OpenStack service should. >> > > Exactly. > I'm evaluating such systems, actually I want to transform events from > openstack into billable items on a billing system. So I store event for > historical queries (accounting service) and send billable info to billing > system to avoid a billing system has to pull openstack. > >> >> 2) Maybe, the ability to register an external web hook for resource so I >> don't have to poll for state changes. This might be purely RESTful, so >> maybe this Nipper service returns 304 and lets the client cache? Does the >> OpenStack API support 304 not modified? I bet it doesn't because it >> doesn't have historical data. >> > I have not found any 304 in the API > >> >> 3) Maybe, the ability to register an billing approval hook into keystone? >> Could be modeled like oauth style transaction. >> > I think we can use the existing X-Auth-Token with a billing system role as > the first approach (i have to look closer) > >> >> ------------------------------------------------- >> Brian Schott, CTO >> Nimbis Services, Inc. >> [email protected] >> ph: 443-274-6064 fx: 443-274-6060 >> >> >> >> On Apr 22, 2012, at 6:54 PM, Luis Gervaso wrote: >> >> You can, but there are more billing providers, i want to provider a point >> where you can choose >> your provider. >> >> I propose 4 possibilities as example: >> >> Scenario1 (this can be the reference implementation): >> >> OpenStack + Dough >> >> Scenario2: >> >> OpenStack + Zoura >> >> Scenario3: >> >> OpenStack + JBilling >> >> Scenario4: >> >> OpenStack + Recurly >> >> On Mon, Apr 23, 2012 at 12:26 AM, Endre Karlson >> <[email protected]>wrote: >> >>> Why can't Dough / Kanyun be used for this? >>> >>> Endre. >>> >>> 2012/4/23 Brian Schott <[email protected]> >>> >>>> 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. >>>> [email protected] >>>> 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 <[email protected]>wrote: >>>> >>>>> Hi, >>>>> Has anyone checked this >>>>> http://www.griddynamics.com/openstack/docs/nova-billing/quickstart.html >>>>> ________________________________________ >>>>> From: >>>>> [email protected][openstack-bounces+atul.jha= >>>>> [email protected]] on behalf of Endre Karlson [ >>>>> [email protected]] >>>>> Sent: Monday, April 23, 2012 2:27 AM >>>>> To: [email protected] >>>>> Subject: Re: [Openstack] Monitoring / Billing Architecture proposed >>>>> >>>>> What is Dough then compared to what you want to do ? >>>>> >>>>> 2012/4/22 Endre Karlson <[email protected]<mailto: >>>>> [email protected]>> >>>>> What is Dough then ? >>>>> >>>>> >>>>> 2012/4/22 Brian Schott <[email protected]<mailto: >>>>> [email protected]>> >>>>> 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. >>>>> [email protected]<mailto:[email protected] >>>>> > >>>>> 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 < >>>>> [email protected]<mailto:[email protected]>> wrote: >>>>> What about using the Dough project? >>>>> >>>>> Endre. >>>>> >>>>> >>>>> 2012/4/22 Endre Karlson <[email protected]<mailto: >>>>> [email protected]>> >>>>> What about using the Dough project ? >>>>> >>>>> Endre. >>>>> >>>>> 2012/4/22 Luis Gervaso <[email protected]<mailto:[email protected]>> >>>>> 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:[email protected]>woorea.es<http://woorea.es/> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~openstack >>>>> Post to : [email protected]<mailto: >>>>> [email protected]> >>>>> Unsubscribe : https://launchpad.net/~openstack >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~openstack >>>>> Post to : [email protected]<mailto: >>>>> [email protected]> >>>>> 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:[email protected]>woorea.es<http://woorea.es/> >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~openstack >>>>> Post to : [email protected]<mailto: >>>>> [email protected]> >>>>> 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 : [email protected] >>>>> 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@ <[email protected]>woorea.es >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~openstack >>>> Post to : [email protected] >>>> Unsubscribe : https://launchpad.net/~openstack >>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~openstack >>>> Post to : [email protected] >>>> Unsubscribe : https://launchpad.net/~openstack >>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~openstack >>> Post to : [email protected] >>> 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@ <[email protected]>woorea.es >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : [email protected] >> 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@ <[email protected]>woorea.es > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
