On 05/16/2012 11:00 PM, Francis J. Lacoste wrote: > > I'm now of the opinion that we exclude storage and API from the metering > project scope. Let's just focus on defining a metering message format, > bus, and maybe a client-library to make it easy to write metering consumers. > > That way we avoid building a lot of things that we only _think will be > useful_ for potential billing integration. Only writing/delivering such > an integration component would prove that we built at least something > that is useful. > >
Hi, I'm a little reluctant to question the whole approach because I'm engaged in it :-) It's scary to contemplate the idea of throwing away some of the work done but I welcome the challenge. Better lose a few days work than keep going in the wrong direction. Are you proposing that such a library would then be integrated in whatever billing system someone has in mind ? For instance Dough https://github.com/lzyeval/dough trystack.org billing https://github.com/trystack/dash_billing nova-billing https://github.com/griddynamics/nova-billing Would depend on this library and rely on its API to collect what they need. The same would be done by proprietary billing systems ? Regarding the relevance of the metrics exposed by the API, I made sure they match the need of the eNovance sales. I'm quite sure Nicolas checked for Canonical and Doug did the same regarding the needs of Dreamhost. I'm confident that the information is actualy useful, at least in these practical cases. Getting rid of the storage imposes a constraint on the billing system : it must make 100% sure that once a message is consumed it will be reliably archived. It also adds a constraint on the chosen bus : it must be able to retain all messages for as long as a consumer needs, which may be days or weeks. Or it adds a constraint on the billing system which must make 100% sure it will consume all relevant messages the bus at all times before they expire. I have no strong feelings about exposing a bus for everyone to use instead of a REST API. I tend to prefer the REST API because it is an established standard for OpenStack. Could you expand on why a bus would be significantly better than a REST API in this specific case ? Cheers -- Loïc Dachary Chief Research Officer // eNovance labs http://labs.enovance.com // ✉ l...@enovance.com ☎ +33 1 49 70 99 82 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
