Mailing List Archive

What about using the Dough project?

Endre.

2012/4/22 Endre Karlson <endre.karlson@gmail.com>

> What about using the Dough project ?
>
> Endre.
>
> 2012/4/22 Luis Gervaso <luis@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
>> luis@ <luis.gervaso@gmail.com>woorea.es
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>

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@gmail.com>wrote:

> What about using the Dough project?
>
> Endre.
>
>
> 2012/4/22 Endre Karlson <endre.karlson@gmail.com>
>
>> What about using the Dough project ?
>>
>> Endre.
>>
>> 2012/4/22 Luis Gervaso <luis@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
>>> luis@ <luis.gervaso@gmail.com>woorea.es
>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@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@ <luis.gervaso@gmail.com>woorea.es

Correct me if I am wrong but mongo has not been used in openstack
previously? What is the benefit here that justifies bringing in new
technology?

Also are you planning an active polling process over AMPQ or passive
listening for the monitor?

It seems to me that most of the main components today can provide
billing data via their API, there's no need to write anything new.
Maybe we should just standardize billing related API queries across
the board?

-Matt

On Sun, Apr 22, 2012 at 12:36 PM, Luis Gervaso <luis@woorea.es> 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@gmail.com>
> wrote:
>>
>> What about using the Dough project?
>>
>> Endre.
>>
>>
>> 2012/4/22 Endre Karlson <endre.karlson@gmail.com>
>>>
>>> What about using the Dough project ?
>>>
>>> Endre.
>>>
>>> 2012/4/22 Luis Gervaso <luis@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
>>>> luis@woorea.es
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to     : openstack@lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@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@woorea.es
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

On Sun, Apr 22, 2012 at 9:57 PM, Matt Joyce <matt@nycresistor.com> wrote:

> Correct me if I am wrong but mongo has not been used in openstack
> previously? What is the benefit here that justifies bringing in new
> technology?
>

Mongo is document oriented, which i consider fits perfectly with the needs.

It allows to query a huge json documents set.

In older version of OpenStack the NoSQL used was Redis, this is key oriented


>
> Also are you planning an active polling process over AMPQ or passive
> listening for the monitor?
>

Listen: The Message Listener will feed MongoDB

>
> It seems to me that most of the main components today can provide
> billing data via their API,


You are right, the mediation has to transform the OpenStack specific data to
the billing priovider. Then using the billing provider API we can feed it.


> there's no need to write anything new.
>

We need to provider a driver for each billing provider


> Maybe we should just standardize billing related API queries across
> the board?
>

I see this option outbound of OpenStack project (actually, this a rougth
estimation ;)

Cheers!


>
> -Matt
>
> On Sun, Apr 22, 2012 at 12:36 PM, Luis Gervaso <luis@woorea.es> 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@gmail.com>
> > wrote:
> >>
> >> What about using the Dough project?
> >>
> >> Endre.
> >>
> >>
> >> 2012/4/22 Endre Karlson <endre.karlson@gmail.com>
> >>>
> >>> What about using the Dough project ?
> >>>
> >>> Endre.
> >>>
> >>> 2012/4/22 Luis Gervaso <luis@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
> >>>> luis@woorea.es
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Mailing list: https://launchpad.net/~openstack
> >>>> Post to : openstack@lists.launchpad.net
> >>>> Unsubscribe : https://launchpad.net/~openstack
> >>>> More help : https://help.launchpad.net/ListHelp
> >>>>
> >>>
> >>
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~openstack
> >> Post to : openstack@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@woorea.es
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to : openstack@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@ <luis.gervaso@gmail.com>woorea.es

Have you started a blueprint and/or Etherpad? We should do that.

Couple of comments:

1. I had an idea for naming the metering service after Nipper, the famous RCA dog :-)
http://en.wikipedia.org/wiki/Nipper

2. A common metering service that listens on Rabbit/ZeroMQ bus for registering events is a good idea, but we need to document some use case scenarios to really nail down the architecture. Who signals the metering service? The API service or nova, quantum, swift, glance, volume? I'd argue that the individual services need to hook into the metering service and that you can't just monitor the message bus for calls from the API service.

- A user launches a flavor A instance of image X through the API service. When nova receives a run_instances request, nova signals nipper with the instance details, the flavor details, and image details. As the instance transitions through its states (pending, starting, running), nova signals nipper on each state change. Nipper will need to have an immutable copy of the current flavor, image, and instance information in case an administrator changes/deletes this information in the future. You want a bill to reflect what resources were consumed, not what the flavor describes when when the bill is generated.

- From within the instance, a user issues a "shutdown -h" command. Nova signals nipper that the state has changed to "shutting down", and then to "stopped" or "terminated" depending on nova's config.

- A user creates a volume of flavor X of size N. (won't the volume service have different flavor of volumes like SSD, sparse, raid-x, ...?). The volume service signals nipper that the volume has been created. Nipper needs to have an immutable copy of the current volume flavor, utilization, and size.

- A user allocates a public IP address. Quantum....

2. A separate "billing" service should have a "pricing" plugin similar to nova's scheduler. This should handle generating "quotes" for a given flavor, image, volume, network, combination and generate invoices as you describe.

3. I'd steer away from mandating implementation technologies in the architecture. MongoDB is fine, but others here would prefer to make their own deployment choices.

Brian

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



On Apr 22, 2012, at 2:50 PM, Luis Gervaso wrote:

> 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
> luis@woorea.es
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp

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@nimbisservices.com
ph: 443-274-6064 fx: 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@gmail.com> wrote:
> What about using the Dough project?
>
> Endre.
>
>
> 2012/4/22 Endre Karlson <endre.karlson@gmail.com>
> What about using the Dough project ?
>
> Endre.
>
> 2012/4/22 Luis Gervaso <luis@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
> luis@woorea.es
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@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@woorea.es
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp

What is Dough then compared to what you want to do ?

2012/4/22 Endre Karlson <endre.karlson@gmail.com>

> What is Dough then ?
>
>
> 2012/4/22 Brian Schott <brian.schott@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@nimbisservices.com
>> ph: 443-274-6064 fx: 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@gmail.com>wrote:
>>
>>> What about using the Dough project?
>>>
>>> Endre.
>>>
>>>
>>> 2012/4/22 Endre Karlson <endre.karlson@gmail.com>
>>>
>>>> What about using the Dough project ?
>>>>
>>>> Endre.
>>>>
>>>> 2012/4/22 Luis Gervaso <luis@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
>>>>> luis@ <luis.gervaso@gmail.com>woorea.es
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~openstack
>>>>> Post to : openstack@lists.launchpad.net
>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@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@ <luis.gervaso@gmail.com>woorea.es
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>>
>

my comments below

On Sun, Apr 22, 2012 at 10:32 PM, Brian Schott <
brian.schott@nimbisservices.com> wrote:

> Have you started a blueprint and/or Etherpad? We should do that.
>
> Couple of comments:
>
> 1. I had an idea for naming the metering service after Nipper, the famous
> RCA dog :-)
> http://en.wikipedia.org/wiki/Nipper
>
> 2. A common metering service that listens on Rabbit/ZeroMQ bus for
> registering events is a good idea, but we need to document some use case
> scenarios to really nail down the architecture. Who signals the metering
> service? The API service or nova, quantum, swift, glance, volume? I'd
> argue that the individual services need to hook into the metering service
> and that you can't just monitor the message bus for calls from the API
> service.
>

Each service should signal the bus, these are the different exchanges/queues

The metering service should subscribe to whatever it wants to be notified,
then react with custom implementation for each event. I identify a template
here:

1. persist the event (useful for accounting)
2. mediate and notify the monitoring tool
3. mediate and notify the billing tool
4. ... (whatever)

Consider than extra billable services like platformlayer (from Justin)
should feed the bus, and the metering should be aware of them in the same
fashion.


> - A user launches a flavor A instance of image X through the API service.
> When nova receives a run_instances request, nova signals nipper with the
> instance details, the flavor details, and image details. As the instance
> transitions through its states (pending, starting, running), nova signals
> nipper on each state change. Nipper will need to have an immutable copy of
> the current flavor, image, and instance information in case an
> administrator changes/deletes this information in the future. You want a
> bill to reflect what resources were consumed, not what the flavor describes
> when when the bill is generated.
>

My vision is that billable systems knows nothing about cloud, they only
know how to bill items. So extra info is for accounting and monitoring.

>
>
> - From within the instance, a user issues a "shutdown -h" command. Nova
> signals nipper that the state has changed to "shutting down", and then to
> "stopped" or "terminated" depending on nova's config.
>

OK


> - A user creates a volume of flavor X of size N. (won't the volume
> service have different flavor of volumes like SSD, sparse, raid-x, ...?).
> The volume service signals nipper that the volume has been created. Nipper
> needs to have an immutable copy of the current volume flavor, utilization,
> and size.
>

I think metering service, is only a dispatcher of asynchronous events to
the specific systems. I mean metering is behind the firewall and billing,
accounting, monitoring should not.

>
> - A user allocates a public IP address. Quantum....
>
> 2. A separate "billing" service should have a "pricing" plugin similar to
> nova's scheduler. This should handle generating "quotes" for a given
> flavor, image, volume, network, combination and generate invoices as you
> describe.
>

Totally agree, this is part of the billing system: for example Dough.
Zuora, whatever

>
> 3. I'd steer away from mandating implementation technologies in the
> architecture. MongoDB is fine, but others here would prefer to make their
> own deployment choices.
>

Agree, I have put them because I am working on a POC using these
technologies

>
> Brian
>

Thanks Brian! I like your vision!

>
> -------------------------------------------------
> Brian Schott, CTO
> Nimbis Services, Inc.
> brian.schott@nimbisservices.com
> ph: 443-274-6064 fx: 443-274-6060
>
>
>
> On Apr 22, 2012, at 2:50 PM, Luis Gervaso wrote:
>
> 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
> luis@ <luis.gervaso@gmail.com>woorea.es
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@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@ <luis.gervaso@gmail.com>woorea.es

Hi,
Has anyone checked this http://www.griddynamics.com/openstack/docs/nova-billing/quickstart.html
________________________________________
From: openstack-bounces+atul.jha=csscorp.com@lists.launchpad.net [openstack-bounces+atul.jha=csscorp.com@lists.launchpad.net] on behalf of Endre Karlson [endre.karlson@gmail.com]
Sent: Monday, April 23, 2012 2:27 AM
To: openstack@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@gmail.com<mailto:endre.karlson@gmail.com>>
What is Dough then ?


2012/4/22 Brian Schott <brian.schott@nimbisservices.com<mailto:brian.schott@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@nimbisservices.com<mailto:brian.schott@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@gmail.com<mailto:endre.karlson@gmail.com>> wrote:
What about using the Dough project?

Endre.


2012/4/22 Endre Karlson <endre.karlson@gmail.com<mailto:endre.karlson@gmail.com>>
What about using the Dough project ?

Endre.

2012/4/22 Luis Gervaso <luis@woorea.es<mailto:luis@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@gmail.com>woorea.es<http://woorea.es/>



_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp




_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net<mailto:openstack@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@gmail.com>woorea.es<http://woorea.es/>

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net<mailto:openstack@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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

On Sun, Apr 22, 2012 at 11:18 PM, Luis Gervaso <luis@woorea.es> wrote:

> I think Dough takes care about pricing and billing.
>
> I have proposed an arch and technologies to fill the gap between openstack
> and
> whatever billing system / monitoring system.
>
>
> On Sun, Apr 22, 2012 at 10:57 PM, Endre Karlson <endre.karlson@gmail.com>wrote:
>
>> What is Dough then compared to what you want to do ?
>>
>> 2012/4/22 Endre Karlson <endre.karlson@gmail.com>
>>
>>> What is Dough then ?
>>>
>>>
>>> 2012/4/22 Brian Schott <brian.schott@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@nimbisservices.com
>>>> ph: 443-274-6064 fx: 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@gmail.com
>>>> > wrote:
>>>>
>>>>> What about using the Dough project?
>>>>>
>>>>> Endre.
>>>>>
>>>>>
>>>>> 2012/4/22 Endre Karlson <endre.karlson@gmail.com>
>>>>>
>>>>>> What about using the Dough project ?
>>>>>>
>>>>>> Endre.
>>>>>>
>>>>>> 2012/4/22 Luis Gervaso <luis@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
>>>>>>> luis@ <luis.gervaso@gmail.com>woorea.es
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Mailing list: https://launchpad.net/~openstack
>>>>>>> Post to : openstack@lists.launchpad.net
>>>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~openstack
>>>>> Post to : openstack@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@ <luis.gervaso@gmail.com>woorea.es
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to : openstack@lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@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@ <luis.gervaso@gmail.com>woorea.es
>
>


--
-------------------------------------------
Luis Alberto Gervaso Martin
Woorea Solutions, S.L
CEO & CTO
mobile: (+34) 627983344
luis@ <luis.gervaso@gmail.com>woorea.es

Dough is a proposed billing service. There was a session at Folsom design summit. This is a practical project for an OpenStack provider with test code on github.
http://summit.openstack.org/sessions/view/37

"
The billing system consists of three components.
1) API Server, which receives subscribe/unsubscribe and usage query requests.
2) Farmer, which periodically checks all subscriptions and requests billing to the collector.
3) Collector, gets work from the farmer and uses python-novaclient, kanyun-client, swift-client to retrieve usage information of a product the tenant has subscribed and charges money to the accordingly.
"
Kanyun is an OpenStack monitoring tool, but I don't see documentation in the code tree (but I've just pulled it to see).
https://github.com/lzyeval

Dough had mixed reviews during the session, but that I think was because it came across as a billing system triggered solely by Horizon requests and was a polled architecture. Given what we have today, I'd implement my own billing/metering system exactly the same way. In fact, I have. Our own e-commerce system at Nimbis works this way with EC2 and OpenStack presently because the only option available is polling periodically and logging the usage data.

Where I'd like to see OpenStack go is metering service that is fully asynchronous and event driven so that I only need to hit the API service when I'm generating an invoice, rather than once per minute because I don't know when an instance was terminated by the user or just crashed.

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



On Apr 22, 2012, at 4:57 PM, Endre Karlson wrote:

> What is Dough then compared to what you want to do ?
>
> 2012/4/22 Endre Karlson <endre.karlson@gmail.com>
> What is Dough then ?
>
>
> 2012/4/22 Brian Schott <brian.schott@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@nimbisservices.com
> ph: 443-274-6064 fx: 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@gmail.com> wrote:
>> What about using the Dough project?
>>
>> Endre.
>>
>>
>> 2012/4/22 Endre Karlson <endre.karlson@gmail.com>
>> What about using the Dough project ?
>>
>> Endre.
>>
>> 2012/4/22 Luis Gervaso <luis@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
>> luis@woorea.es
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@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@woorea.es
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp

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@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@lists.launchpad.net[openstack-bounces+atul.jha=
> csscorp.com@lists.launchpad.net] on behalf of Endre Karlson [
> endre.karlson@gmail.com]
> Sent: Monday, April 23, 2012 2:27 AM
> To: openstack@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@gmail.com<mailto:
> endre.karlson@gmail.com>>
> What is Dough then ?
>
>
> 2012/4/22 Brian Schott <brian.schott@nimbisservices.com<mailto:
> brian.schott@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@nimbisservices.com<mailto:brian.schott@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@gmail.com
> <mailto:endre.karlson@gmail.com>> wrote:
> What about using the Dough project?
>
> Endre.
>
>
> 2012/4/22 Endre Karlson <endre.karlson@gmail.com<mailto:
> endre.karlson@gmail.com>>
> What about using the Dough project ?
>
> Endre.
>
> 2012/4/22 Luis Gervaso <luis@woorea.es<mailto:luis@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@gmail.com>woorea.es<http://woorea.es/>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net<mailto:
> openstack@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net<mailto:
> openstack@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@gmail.com>woorea.es<http://woorea.es/>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net<mailto:
> openstack@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@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@ <luis.gervaso@gmail.com>woorea.es

Some of the links are broken in the wiki because the github projects got renamed recently to better mesh with OpenStack projects.
The code is here:
https://github.com/griddynamics/nova-billing

You would also need all of their forks of nova, swift, etc.

If the GD guys are tracking this list, what is the status with respect to merging with trunk? The project looks interesting and much further along that I though.

Brian

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



On Apr 22, 2012, at 5:16 PM, Atul Jha wrote:

> Hi,
> Has anyone checked this http://www.griddynamics.com/openstack/docs/nova-billing/quickstart.html
> ________________________________________
> From: openstack-bounces+atul.jha=csscorp.com@lists.launchpad.net [openstack-bounces+atul.jha=csscorp.com@lists.launchpad.net] on behalf of Endre Karlson [endre.karlson@gmail.com]
> Sent: Monday, April 23, 2012 2:27 AM
> To: openstack@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@gmail.com<mailto:endre.karlson@gmail.com>>
> What is Dough then ?
>
>
> 2012/4/22 Brian Schott <brian.schott@nimbisservices.com<mailto:brian.schott@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@nimbisservices.com<mailto:brian.schott@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@gmail.com<mailto:endre.karlson@gmail.com>> wrote:
> What about using the Dough project?
>
> Endre.
>
>
> 2012/4/22 Endre Karlson <endre.karlson@gmail.com<mailto:endre.karlson@gmail.com>>
> What about using the Dough project ?
>
> Endre.
>
> 2012/4/22 Luis Gervaso <luis@woorea.es<mailto:luis@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@gmail.com>woorea.es<http://woorea.es/>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net<mailto:openstack@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@gmail.com>woorea.es<http://woorea.es/>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net<mailto:openstack@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@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp

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@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@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@lists.launchpad.net [openstack-bounces+atul.jha=csscorp.com@lists.launchpad.net] on behalf of Endre Karlson [endre.karlson@gmail.com]
> Sent: Monday, April 23, 2012 2:27 AM
> To: openstack@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@gmail.com<mailto:endre.karlson@gmail.com>>
> What is Dough then ?
>
>
> 2012/4/22 Brian Schott <brian.schott@nimbisservices.com<mailto:brian.schott@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@nimbisservices.com<mailto:brian.schott@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@gmail.com<mailto:endre.karlson@gmail.com>> wrote:
> What about using the Dough project?
>
> Endre.
>
>
> 2012/4/22 Endre Karlson <endre.karlson@gmail.com<mailto:endre.karlson@gmail.com>>
> What about using the Dough project ?
>
> Endre.
>
> 2012/4/22 Luis Gervaso <luis@woorea.es<mailto:luis@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@gmail.com>woorea.es<http://woorea.es/>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net<mailto:openstack@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@gmail.com>woorea.es<http://woorea.es/>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net<mailto:openstack@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@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@woorea.es
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp

I agree.

Keypoint: Metering always feeds an accounting system

Then, 2 possible scenarios:

1) Meetering also feeds billing system (this is a sync operation)
2) Meetering does *not* feeds billing system. Then : The billing system has
to pull the accounting system, then the billing system can't be an external
SaaS. (I don't like this option, too coupled)




On Sun, Apr 22, 2012 at 11:29 PM, Brian Schott <
brian.schott@nimbisservices.com> wrote:

> Dough is a proposed billing service. There was a session at Folsom design
> summit. This is a practical project for an OpenStack provider with test
> code on github.
> http://summit.openstack.org/sessions/view/37
>
> "
> The billing system consists of three components.
> 1) API Server, which receives subscribe/unsubscribe and usage query
> requests.
> 2) Farmer, which periodically checks all subscriptions and requests
> billing to the collector.
> 3) Collector, gets work from the farmer and uses python-novaclient,
> kanyun-client, swift-client to retrieve usage information of a product the
> tenant has subscribed and charges money to the accordingly.
> "
> Kanyun is an OpenStack monitoring tool, but I don't see documentation in
> the code tree (but I've just pulled it to see).
> https://github.com/lzyeval
>
> Dough had mixed reviews during the session, but that I think was because
> it came across as a billing system triggered solely by Horizon requests and
> was a polled architecture. Given what we have today, I'd implement my own
> billing/metering system exactly the same way. In fact, I have. Our own
> e-commerce system at Nimbis works this way with EC2 and OpenStack presently
> because the only option available is polling periodically and logging the
> usage data.
>
> Where I'd like to see OpenStack go is metering service that is fully
> asynchronous and event driven so that I only need to hit the API service
> when I'm generating an invoice, rather than once per minute because I don't
> know when an instance was terminated by the user or just crashed.
>
> -------------------------------------------------
> Brian Schott, CTO
> Nimbis Services, Inc.
> brian.schott@nimbisservices.com
> ph: 443-274-6064 fx: 443-274-6060
>
>
>
> On Apr 22, 2012, at 4:57 PM, Endre Karlson wrote:
>
> What is Dough then compared to what you want to do ?
>
> 2012/4/22 Endre Karlson <endre.karlson@gmail.com>
>
>> What is Dough then ?
>>
>>
>> 2012/4/22 Brian Schott <brian.schott@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@nimbisservices.com
>>> ph: 443-274-6064 fx: 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@gmail.com>wrote:
>>>
>>>> What about using the Dough project?
>>>>
>>>> Endre.
>>>>
>>>>
>>>> 2012/4/22 Endre Karlson <endre.karlson@gmail.com>
>>>>
>>>>> What about using the Dough project ?
>>>>>
>>>>> Endre.
>>>>>
>>>>> 2012/4/22 Luis Gervaso <luis@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
>>>>>> luis@ <luis.gervaso@gmail.com>woorea.es
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~openstack
>>>>>> Post to : openstack@lists.launchpad.net
>>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to : openstack@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@ <luis.gervaso@gmail.com>woorea.es
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help : https://help.launchpad.net/ListHelp
>>>
>>>
>>>
>>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@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@ <luis.gervaso@gmail.com>woorea.es

Monitoring and billing seem to be two VERY different beasts.

Should we be separating the two efforts?

On Sun, Apr 22, 2012 at 3:08 PM, Brian Schott
<brian.schott@nimbisservices.com> wrote:
> 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@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@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@lists.launchpad.net
>> [openstack-bounces+atul.jha=csscorp.com@lists.launchpad.net] on behalf of
>> Endre Karlson [endre.karlson@gmail.com]
>> Sent: Monday, April 23, 2012 2:27 AM
>> To: openstack@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@gmail.com<mailto:endre.karlson@gmail.com>>
>> What is Dough then ?
>>
>>
>> 2012/4/22 Brian Schott
>> <brian.schott@nimbisservices.com<mailto:brian.schott@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@nimbisservices.com<mailto:brian.schott@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@gmail.com<mailto:endre.karlson@gmail.com>> wrote:
>> What about using the Dough project?
>>
>> Endre.
>>
>>
>> 2012/4/22 Endre Karlson
>> <endre.karlson@gmail.com<mailto:endre.karlson@gmail.com>>
>> What about using the Dough project ?
>>
>> Endre.
>>
>> 2012/4/22 Luis Gervaso <luis@woorea.es<mailto:luis@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@gmail.com>woorea.es<http://woorea.es/>
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     :
>> openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     :
>> openstack@lists.launchpad.net<mailto:openstack@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@gmail.com>woorea.es<http://woorea.es/>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     :
>> openstack@lists.launchpad.net<mailto:openstack@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@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@woorea.es
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

Why can't Dough / Kanyun be used for this?

Endre.

2012/4/23 Brian Schott <brian.schott@nimbisservices.com>

> 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@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@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@lists.launchpad.net[openstack-bounces+atul.jha=
>> csscorp.com@lists.launchpad.net] on behalf of Endre Karlson [
>> endre.karlson@gmail.com]
>> Sent: Monday, April 23, 2012 2:27 AM
>> To: openstack@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@gmail.com<mailto:
>> endre.karlson@gmail.com>>
>> What is Dough then ?
>>
>>
>> 2012/4/22 Brian Schott <brian.schott@nimbisservices.com<mailto:
>> brian.schott@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@nimbisservices.com<mailto:brian.schott@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@gmail.com
>> <mailto:endre.karlson@gmail.com>> wrote:
>> What about using the Dough project?
>>
>> Endre.
>>
>>
>> 2012/4/22 Endre Karlson <endre.karlson@gmail.com<mailto:
>> endre.karlson@gmail.com>>
>> What about using the Dough project ?
>>
>> Endre.
>>
>> 2012/4/22 Luis Gervaso <luis@woorea.es<mailto:luis@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@gmail.com>woorea.es<http://woorea.es/>
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net<mailto:
>> openstack@lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net<mailto:
>> openstack@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@gmail.com>woorea.es<http://woorea.es/>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net<mailto:
>> openstack@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@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@ <luis.gervaso@gmail.com>woorea.es
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>

You are right.

"OpenStack should do only cloudcomputing. Others should manage better
monitor and billing"

So we have to focus the effort to define the piece/component that
orchestates the two/three/four ... beasts
around OpenStack in a loosely coupled way.

That is, other *should not* know OpenStack internals to do their work.


On Mon, Apr 23, 2012 at 12:22 AM, Matt Joyce <matt@nycresistor.com> wrote:

> Monitoring and billing seem to be two VERY different beasts.
>
> Should we be separating the two efforts?
>
> On Sun, Apr 22, 2012 at 3:08 PM, Brian Schott
> <brian.schott@nimbisservices.com> wrote:
> > 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@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@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@lists.launchpad.net
> >> [openstack-bounces+atul.jha=csscorp.com@lists.launchpad.net] on behalf
> of
> >> Endre Karlson [endre.karlson@gmail.com]
> >> Sent: Monday, April 23, 2012 2:27 AM
> >> To: openstack@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@gmail.com<mailto:endre.karlson@gmail.com>>
> >> What is Dough then ?
> >>
> >>
> >> 2012/4/22 Brian Schott
> >> <brian.schott@nimbisservices.com<mailto:brian.schott@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@nimbisservices.com<mailto:brian.schott@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@gmail.com<mailto:endre.karlson@gmail.com>> wrote:
> >> What about using the Dough project?
> >>
> >> Endre.
> >>
> >>
> >> 2012/4/22 Endre Karlson
> >> <endre.karlson@gmail.com<mailto:endre.karlson@gmail.com>>
> >> What about using the Dough project ?
> >>
> >> Endre.
> >>
> >> 2012/4/22 Luis Gervaso <luis@woorea.es<mailto:luis@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@gmail.com>woorea.es<http://woorea.es/>
> >>
> >>
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~openstack
> >> Post to :
> >> openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>
> >> Unsubscribe : https://launchpad.net/~openstack
> >> More help : https://help.launchpad.net/ListHelp
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~openstack
> >> Post to :
> >> openstack@lists.launchpad.net<mailto:openstack@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@gmail.com>woorea.es<http://woorea.es/>
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~openstack
> >> Post to :
> >> openstack@lists.launchpad.net<mailto:openstack@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@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@woorea.es
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to : openstack@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help : https://help.launchpad.net/ListHelp
> >
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to : openstack@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@ <luis.gervaso@gmail.com>woorea.es

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@gmail.com>wrote:

> Why can't Dough / Kanyun be used for this?
>
> Endre.
>
> 2012/4/23 Brian Schott <brian.schott@nimbisservices.com>
>
>> 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@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@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@lists.launchpad.net[openstack-bounces+atul.jha=
>>> csscorp.com@lists.launchpad.net] on behalf of Endre Karlson [
>>> endre.karlson@gmail.com]
>>> Sent: Monday, April 23, 2012 2:27 AM
>>> To: openstack@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@gmail.com<mailto:
>>> endre.karlson@gmail.com>>
>>> What is Dough then ?
>>>
>>>
>>> 2012/4/22 Brian Schott <brian.schott@nimbisservices.com<mailto:
>>> brian.schott@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@nimbisservices.com<mailto:brian.schott@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@gmail.com
>>> <mailto:endre.karlson@gmail.com>> wrote:
>>> What about using the Dough project?
>>>
>>> Endre.
>>>
>>>
>>> 2012/4/22 Endre Karlson <endre.karlson@gmail.com<mailto:
>>> endre.karlson@gmail.com>>
>>> What about using the Dough project ?
>>>
>>> Endre.
>>>
>>> 2012/4/22 Luis Gervaso <luis@woorea.es<mailto:luis@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@gmail.com>woorea.es<http://woorea.es/>
>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net<mailto:
>>> openstack@lists.launchpad.net>
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help : https://help.launchpad.net/ListHelp
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net<mailto:
>>> openstack@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@gmail.com>woorea.es<http://woorea.es/>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net<mailto:
>>> openstack@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@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@ <luis.gervaso@gmail.com>woorea.es
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@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@ <luis.gervaso@gmail.com>woorea.es

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.

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.

3) Maybe, the ability to register an billing approval hook into keystone? Could be modeled like oauth style transaction.

-------------------------------------------------
Brian Schott, CTO
Nimbis Services, Inc.
brian.schott@nimbisservices.com
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@gmail.com> wrote:
> Why can't Dough / Kanyun be used for this?
>
> Endre.
>
> 2012/4/23 Brian Schott <brian.schott@nimbisservices.com>
> 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@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@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@lists.launchpad.net [openstack-bounces+atul.jha=csscorp.com@lists.launchpad.net] on behalf of Endre Karlson [endre.karlson@gmail.com]
>> Sent: Monday, April 23, 2012 2:27 AM
>> To: openstack@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@gmail.com<mailto:endre.karlson@gmail.com>>
>> What is Dough then ?
>>
>>
>> 2012/4/22 Brian Schott <brian.schott@nimbisservices.com<mailto:brian.schott@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@nimbisservices.com<mailto:brian.schott@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@gmail.com<mailto:endre.karlson@gmail.com>> wrote:
>> What about using the Dough project?
>>
>> Endre.
>>
>>
>> 2012/4/22 Endre Karlson <endre.karlson@gmail.com<mailto:endre.karlson@gmail.com>>
>> What about using the Dough project ?
>>
>> Endre.
>>
>> 2012/4/22 Luis Gervaso <luis@woorea.es<mailto:luis@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@gmail.com>woorea.es<http://woorea.es/>
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net<mailto:openstack@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@gmail.com>woorea.es<http://woorea.es/>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net<mailto:openstack@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@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@woorea.es
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@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@woorea.es
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp

On Mon, Apr 23, 2012 at 2:10 AM, Brian Schott <
brian.schott@nimbisservices.com> 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@nimbisservices.com
> 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@gmail.com>wrote:
>
>> Why can't Dough / Kanyun be used for this?
>>
>> Endre.
>>
>> 2012/4/23 Brian Schott <brian.schott@nimbisservices.com>
>>
>>> 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@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@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@lists.launchpad.net[openstack-bounces+atul.jha=
>>>> csscorp.com@lists.launchpad.net] on behalf of Endre Karlson [
>>>> endre.karlson@gmail.com]
>>>> Sent: Monday, April 23, 2012 2:27 AM
>>>> To: openstack@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@gmail.com<mailto:
>>>> endre.karlson@gmail.com>>
>>>> What is Dough then ?
>>>>
>>>>
>>>> 2012/4/22 Brian Schott <brian.schott@nimbisservices.com<mailto:
>>>> brian.schott@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@nimbisservices.com<mailto:brian.schott@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@gmail.com
>>>> <mailto:endre.karlson@gmail.com>> wrote:
>>>> What about using the Dough project?
>>>>
>>>> Endre.
>>>>
>>>>
>>>> 2012/4/22 Endre Karlson <endre.karlson@gmail.com<mailto:
>>>> endre.karlson@gmail.com>>
>>>> What about using the Dough project ?
>>>>
>>>> Endre.
>>>>
>>>> 2012/4/22 Luis Gervaso <luis@woorea.es<mailto:luis@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@gmail.com>woorea.es<http://woorea.es/>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to : openstack@lists.launchpad.net<mailto:
>>>> openstack@lists.launchpad.net>
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to : openstack@lists.launchpad.net<mailto:
>>>> openstack@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@gmail.com>woorea.es<http://woorea.es/>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to : openstack@lists.launchpad.net<mailto:
>>>> openstack@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@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@ <luis.gervaso@gmail.com>woorea.es
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help : https://help.launchpad.net/ListHelp
>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@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@ <luis.gervaso@gmail.com>woorea.es
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@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@ <luis.gervaso@gmail.com>woorea.es

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 <luis@woorea.es> wrote:

>
>
> On Mon, Apr 23, 2012 at 2:10 AM, Brian Schott <
> brian.schott@nimbisservices.com> 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@nimbisservices.com
>> 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@gmail.com>wrote:
>>
>>> Why can't Dough / Kanyun be used for this?
>>>
>>> Endre.
>>>
>>> 2012/4/23 Brian Schott <brian.schott@nimbisservices.com>
>>>
>>>> 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@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@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@lists.launchpad.net[openstack-bounces+atul.jha=
>>>>> csscorp.com@lists.launchpad.net] on behalf of Endre Karlson [
>>>>> endre.karlson@gmail.com]
>>>>> Sent: Monday, April 23, 2012 2:27 AM
>>>>> To: openstack@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@gmail.com<mailto:
>>>>> endre.karlson@gmail.com>>
>>>>> What is Dough then ?
>>>>>
>>>>>
>>>>> 2012/4/22 Brian Schott <brian.schott@nimbisservices.com<mailto:
>>>>> brian.schott@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@nimbisservices.com<mailto:brian.schott@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@gmail.com<mailto:endre.karlson@gmail.com>> wrote:
>>>>> What about using the Dough project?
>>>>>
>>>>> Endre.
>>>>>
>>>>>
>>>>> 2012/4/22 Endre Karlson <endre.karlson@gmail.com<mailto:
>>>>> endre.karlson@gmail.com>>
>>>>> What about using the Dough project ?
>>>>>
>>>>> Endre.
>>>>>
>>>>> 2012/4/22 Luis Gervaso <luis@woorea.es<mailto:luis@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@gmail.com>woorea.es<http://woorea.es/>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~openstack
>>>>> Post to : openstack@lists.launchpad.net<mailto:
>>>>> openstack@lists.launchpad.net>
>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~openstack
>>>>> Post to : openstack@lists.launchpad.net<mailto:
>>>>> openstack@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@gmail.com>woorea.es<http://woorea.es/>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~openstack
>>>>> Post to : openstack@lists.launchpad.net<mailto:
>>>>> openstack@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@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@ <luis.gervaso@gmail.com>woorea.es
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to : openstack@lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to : openstack@lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@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@ <luis.gervaso@gmail.com>woorea.es
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@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@ <luis.gervaso@gmail.com>woorea.es
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>

Congrats for the project!

On Mon, Apr 23, 2012 at 3:06 AM, Zhongyue Luo <lzyeval@gmail.com> 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@woorea.es> wrote:
>
>>
>>
>> On Mon, Apr 23, 2012 at 2:10 AM, Brian Schott <
>> brian.schott@nimbisservices.com> 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@nimbisservices.com
>>> 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@gmail.com
>>> > wrote:
>>>
>>>> Why can't Dough / Kanyun be used for this?
>>>>
>>>> Endre.
>>>>
>>>> 2012/4/23 Brian Schott <brian.schott@nimbisservices.com>
>>>>
>>>>> 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@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@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@lists.launchpad.net[openstack-bounces+atul.jha=
>>>>>> csscorp.com@lists.launchpad.net] on behalf of Endre Karlson [
>>>>>> endre.karlson@gmail.com]
>>>>>> Sent: Monday, April 23, 2012 2:27 AM
>>>>>> To: openstack@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@gmail.com<mailto:
>>>>>> endre.karlson@gmail.com>>
>>>>>> What is Dough then ?
>>>>>>
>>>>>>
>>>>>> 2012/4/22 Brian Schott <brian.schott@nimbisservices.com<mailto:
>>>>>> brian.schott@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@nimbisservices.com<mailto:
>>>>>> brian.schott@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@gmail.com<mailto:endre.karlson@gmail.com>> wrote:
>>>>>> What about using the Dough project?
>>>>>>
>>>>>> Endre.
>>>>>>
>>>>>>
>>>>>> 2012/4/22 Endre Karlson <endre.karlson@gmail.com<mailto:
>>>>>> endre.karlson@gmail.com>>
>>>>>> What about using the Dough project ?
>>>>>>
>>>>>> Endre.
>>>>>>
>>>>>> 2012/4/22 Luis Gervaso <luis@woorea.es<mailto:luis@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@gmail.com>woorea.es<http://woorea.es/>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~openstack
>>>>>> Post to : openstack@lists.launchpad.net<mailto:
>>>>>> openstack@lists.launchpad.net>
>>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~openstack
>>>>>> Post to : openstack@lists.launchpad.net<mailto:
>>>>>> openstack@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@gmail.com>woorea.es<http://woorea.es/>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~openstack
>>>>>> Post to : openstack@lists.launchpad.net<mailto:
>>>>>> openstack@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@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@ <luis.gervaso@gmail.com>woorea.es
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~openstack
>>>>> Post to : openstack@lists.launchpad.net
>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~openstack
>>>>> Post to : openstack@lists.launchpad.net
>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to : openstack@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@ <luis.gervaso@gmail.com>woorea.es
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@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@ <luis.gervaso@gmail.com>woorea.es
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@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@ <luis.gervaso@gmail.com>woorea.es

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

-------------------------------------------------
Brian Schott, CTO
Nimbis Services, Inc.
brian.schott@nimbisservices.com
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@gmail.com> 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@woorea.es> wrote:
>
>
> On Mon, Apr 23, 2012 at 2:10 AM, Brian Schott <brian.schott@nimbisservices.com> 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@nimbisservices.com
> 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@gmail.com> wrote:
>> Why can't Dough / Kanyun be used for this?
>>
>> Endre.
>>
>> 2012/4/23 Brian Schott <brian.schott@nimbisservices.com>
>> 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@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@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@lists.launchpad.net [openstack-bounces+atul.jha=csscorp.com@lists.launchpad.net] on behalf of Endre Karlson [endre.karlson@gmail.com]
>>> Sent: Monday, April 23, 2012 2:27 AM
>>> To: openstack@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@gmail.com<mailto:endre.karlson@gmail.com>>
>>> What is Dough then ?
>>>
>>>
>>> 2012/4/22 Brian Schott <brian.schott@nimbisservices.com<mailto:brian.schott@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@nimbisservices.com<mailto:brian.schott@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@gmail.com<mailto:endre.karlson@gmail.com>> wrote:
>>> What about using the Dough project?
>>>
>>> Endre.
>>>
>>>
>>> 2012/4/22 Endre Karlson <endre.karlson@gmail.com<mailto:endre.karlson@gmail.com>>
>>> What about using the Dough project ?
>>>
>>> Endre.
>>>
>>> 2012/4/22 Luis Gervaso <luis@woorea.es<mailto:luis@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@gmail.com>woorea.es<http://woorea.es/>
>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help : https://help.launchpad.net/ListHelp
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net<mailto:openstack@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@gmail.com>woorea.es<http://woorea.es/>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net<mailto:openstack@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@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@woorea.es
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help : https://help.launchpad.net/ListHelp
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@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@woorea.es
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@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@woorea.es
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@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@woorea.es
>