openstack team mailing list archive

[Luis Gervaso <luis@xxxxxxxxx>]

Nick, I want contribute in the discussion group.

I have seen yagi implementation, and i like it. I like the protocol.

But I think that it's a protocol that fits very well when no sensible data
is involved (content feeds). When money, resources, companies are involved
i think we need to use a more elaborated schema.

I don't like the 3rd parties have to pull, my proporsal here is that 3rd
parties can be entities externalized outside of the datacenter.

1. i don't want to make the accounting public accessible for security
reasons.
2. 3rd parties can't be coupled to openstack, i want to feed them. I think
this is the key.

What i realized is that the listener needs to feed the billing system
following the rules/api of the selected billing system.

Scenario:

1. A company has an account on a billing provider
2. A company should define the pricing model in the billing system, outside
openstack (i.e: inside zuora, jbilling, recurly, dough)
3. When a message arrives to the listener the listener has to perform the
following actions:

3a: transform and store the message in a accounting system (restful api)
3b (optional): transform and store the message in a billing system (restful
api) example: [
http://knowledgecenter.zuora.com/C_Zuora_User_Guides/A_Billing_and_Payments/A_Z-Billing
]
3c (optional): perform monitoring (currently evaluating sigar functionality)

3a: is openstack related

3b, 3c, ...: are hooks

4a. A company can query the billing system to gather the bills (no
openstack dependencies)
4b. A company can query the monitoring system (no openstack dependencies)

Regarding MongoDB, I recommend a document oriented database where we can
query with criteria. Redis is key-value oriented.

Cheers!

On Mon, Apr 23, 2012 at 4:51 PM, Kevin L. Mitchell <
kevin.mitchell@xxxxxxxxxxxxx> wrote:

> On Sun, 2012-04-22 at 20:50 +0200, Luis Gervaso wrote:
> > 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)
>
> Except for the use of MongoDB, the above seems to me to be almost
> identical to the notifications system already in Nova, which Yagi
> consumes.  Have you looked at our existing notifications?  Yagi?  One or
> both might solve at least parts of your problem…
>
> --
> Kevin L. Mitchell <kevin.mitchell@xxxxxxxxxxxxx>
>
>
> _______________________________________________
> 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