Open Stack

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

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