openstack team mailing list archive

[Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx>]

On Fri, May 18, 2012 at 5:27 AM, Thierry Carrez <thierry@xxxxxxxxxxxxx>wrote:

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


I can see some benefit to that, especially when it comes to validating the
message signatures.

Doug