Open Stack

Doug Hellmann wrote:
> On Thu, May 17, 2012 at 5:47 AM, Nick Barcet <nick.barcet at canonical.com
> <mailto:nick.barcet at 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