openstack team mailing list archive

[Luis Gervaso <luis@xxxxxxxxx>]

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@ <luis.gervaso@xxxxxxxxx>woorea.es
>>>>>
>>>>>  _______________________________________________
>>>>> 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@ <luis.gervaso@xxxxxxxxx>woorea.es
>>>
>>>  _______________________________________________
>>> 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@ <luis.gervaso@xxxxxxxxx>woorea.es
>>
>>
>> _______________________________________________
>> 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@ <luis.gervaso@xxxxxxxxx>woorea.es