On 12-05-17 08:14 AM, Doug Hellmann wrote: > > > On Thu, May 17, 2012 at 5:47 AM, Nick Barcet <nick.bar...@canonical.com > <mailto:nick.bar...@canonical.com>> wrote: > > On 05/17/2012 11:13 AM, Loic Dachary wrote: > > 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. > > > The plan, as I understand it, is to ensure that all metering messages > appear on a common bus using a documented format. Deployers who do not > want the storage system and REST API will not need to use it, and can > set up their own clients to listen on that bus. I'm not sure how much of > a client library is needed, since the bus is AMQP and the messages are > JSON, both of which have standard libraries in most common languages.
Like Thierry Carrez mentioned, the main use for a library was to handle validation of message signature in a handy fashion. Bug I agree that this client library would just be a thin convenience wrapper around the bus protocol. > > > > > 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. > > > That's exactly right. It will be easier for me to bridge between our two > systems by pulling a day's worth of details from the ceilometer API and > storing them in the billing system using a batch job, rather than trying > to ensure that the billing database performs well enough to record the > information in real time. My goal is to not have to change the billing > system at all. That's good information to have. Which means that a REST API + storage component definitively has some values for some integration cases. -- Francis J. Lacoste francis.laco...@canonical.com
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp