<br><br><div class="gmail_quote">On Fri, May 18, 2012 at 5:27 AM, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">Doug Hellmann wrote:<br>
> On Thu, May 17, 2012 at 5:47 AM, Nick Barcet <<a href="mailto:nick.barcet@canonical.com">nick.barcet@canonical.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:nick.barcet@canonical.com">nick.barcet@canonical.com</a>>> wrote:<br>
><br>
>     On 05/17/2012 11:13 AM, Loic Dachary wrote:<br>
>     > On 05/16/2012 11:00 PM, Francis J. Lacoste wrote:<br>
>     >><br>
>     >> I'm now of the opinion that we exclude storage and API from the<br>
>     >> metering project scope. Let's just focus on defining a metering<br>
>     >> message format, bus, and maybe a client-library to make it easy to<br>
>     >> write metering consumers.<br>
><br>
><br>
> The plan, as I understand it, is to ensure that all metering messages<br>
> appear on a common bus using a documented format. Deployers who do not<br>
> want the storage system and REST API will not need to use it, and can<br>
> set up their own clients to listen on that bus. I'm not sure how much of<br>
> a client library is needed, since the bus is AMQP and the messages are<br>
> JSON, both of which have standard libraries in most common languages.<br>
</div>> [...]<br>
<br>
You can certainly architect it in a way so that storage and API are<br>
optional: expose metering messages on the bus, and provide an<br>
optionally-run aggregation component that exposes a REST API (and that<br>
would use the metering-consumer client library). That would give<br>
deployers the option to poll via REST or implement their own alternate<br>
aggregation using the metering-consumer client lib, depending on the<br>
system they need to integrate with.<br>
<br>
Having the aggregation component clearly separate and optional will<br>
serve as a great example of how it could be done (and what are the<br>
responsibilities of the aggregation component). I would still do a<br>
(minimal) client library to facilitate integration, but maybe that's<br>
just me :)</blockquote><div><br></div><div>I can see some benefit to that, especially when it comes to validating the message signatures.</div><div><br></div><div>Doug</div><div><br></div></div>