openstack team mailing list archive

[Brian Schott <brian.schott@xxxxxxxxxxxxxxxxxx>]

I captured some of our discussion in the etherpad, but feel free to extend.
Brian

-------------------------------------------------
Brian Schott, CTO
Nimbis Services, Inc.
brian.schott@xxxxxxxxxxxxxxxxxx
ph: 443-274-6064  fx: 443-274-6060



On Apr 22, 2012, at 9:32 PM, Luis Gervaso wrote:

> Congrats for the project!
> 
> On Mon, Apr 23, 2012 at 3:06 AM, Zhongyue Luo <lzyeval@xxxxxxxxx> wrote:
> 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.
> 
> This happen every time "what works for your business does not for mine" I think the response is: "You can use if works for you ..." 
> 
> 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.
> 
> It sound really good! Anycase I think the billing should be outside the OpenStack realm. A bunch of work is necessary to do the metering and the following integrations
> 
> 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.
> 
> Can be seen Dough as a success history of OpenStack Billing integration?
>  
> Cheers,
> LZY
> 
> 
> On Sun, Apr 22, 2012 at 5:43 PM, Luis Gervaso <luis@xxxxxxxxx> wrote:
> 
> 
> On Mon, Apr 23, 2012 at 2:10 AM, Brian Schott <brian.schott@xxxxxxxxxxxxxxxxxx> 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.
> brian.schott@xxxxxxxxxxxxxxxxxx
> 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 <endre.karlson@xxxxxxxxx> wrote:
>> Why can't Dough / Kanyun be used for this?
>> 
>> Endre.
>> 
>> 2012/4/23 Brian Schott <brian.schott@xxxxxxxxxxxxxxxxxx>
>> 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@xxxxxxxxxxxxxxxxxx
>> 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@xxxxxxxxxxx> wrote:
>>> Hi,
>>> Has anyone checked this http://www.griddynamics.com/openstack/docs/nova-billing/quickstart.html
>>> ________________________________________
>>> From: openstack-bounces+atul.jha=csscorp.com@xxxxxxxxxxxxxxxxxxx [openstack-bounces+atul.jha=csscorp.com@xxxxxxxxxxxxxxxxxxx] on behalf of Endre Karlson [endre.karlson@xxxxxxxxx]
>>> Sent: Monday, April 23, 2012 2:27 AM
>>> To: openstack@xxxxxxxxxxxxxxxxxxx
>>> 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@xxxxxxxxx<mailto:endre.karlson@xxxxxxxxx>>
>>> What is Dough then ?
>>> 
>>> 
>>> 2012/4/22 Brian Schott <brian.schott@xxxxxxxxxxxxxxxxxx<mailto:brian.schott@xxxxxxxxxxxxxxxxxx>>
>>> 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@xxxxxxxxxxxxxxxxxx<mailto:brian.schott@xxxxxxxxxxxxxxxxxx>
>>> 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@xxxxxxxxx<mailto:endre.karlson@xxxxxxxxx>> wrote:
>>> What about using the Dough project?
>>> 
>>> Endre.
>>> 
>>> 
>>> 2012/4/22 Endre Karlson <endre.karlson@xxxxxxxxx<mailto:endre.karlson@xxxxxxxxx>>
>>> What about using the Dough project ?
>>> 
>>> Endre.
>>> 
>>> 2012/4/22 Luis Gervaso <luis@xxxxxxxxx<mailto:luis@xxxxxxxxx>>
>>> 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@xxxxxxxxx>woorea.es<http://woorea.es/>
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
>>> 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@xxxxxxxxx>woorea.es<http://woorea.es/>
>>> 
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
>>> 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@xxxxxxxxxxxxxxxxxxx
>>> 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@xxxxxxxxx
>>> 
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>> 
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>> 
>> 
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> 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@xxxxxxxxx
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> 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@xxxxxxxxx
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxx
>

Attachment: smime.p7s
Description: S/MIME cryptographic signature