openstack team mailing list archive

[Luis Gervaso <luis@xxxxxxxxx>]

my comments below

On Sun, Apr 22, 2012 at 10:32 PM, Brian Schott <
brian.schott@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxx>woorea.es
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>


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