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. > [...]
You can certainly architect it in a way so that storage and API are optional: expose metering messages on the bus, and provide an optionally-run aggregation component that exposes a REST API (and that would use the metering-consumer client library). That would give deployers the option to poll via REST or implement their own alternate aggregation using the metering-consumer client lib, depending on the system they need to integrate with. Having the aggregation component clearly separate and optional will serve as a great example of how it could be done (and what are the responsibilities of the aggregation component). I would still do a (minimal) client library to facilitate integration, but maybe that's just me :) -- Thierry Carrez (ttx) Release Manager, OpenStack _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp