<br><br><div class="gmail_quote">On Fri, May 18, 2012 at 4:53 PM, Francis J. Lacoste <span dir="ltr"><<a href="mailto:francis.lacoste@canonical.com" target="_blank">francis.lacoste@canonical.com</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">On 12-05-18 05:27 AM, Thierry Carrez wrote:<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 :)<br>
<br>
</div>Right, I like this approach very much.<br>
<br>
The main thing I'm worried about is that we are building a system that<br>
has no use in _itself_. It's all about enabling integration in<br>
third-party billing system, but we aren't building such an integration<br>
as part of this project.<br></blockquote><div><br></div><div>Well, several of us actually *are* building such integration systems at the same time that we are building ceilometer. That's where these requirements are coming from! :-) I don't expect to be releasing all of the code for that integration, but I will release what I can and I am happy to talk about the general requirements and constraints for the rest on the list to help with the design of ceilometer.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We could easily implement something that lacks our focus. Maybe, that's<br>
an argument for building a simple billing app as part of OpenStack as a<br>
proof of concept that the metering system can be integrated.<br></blockquote><div><br></div><div>I would not object if you wanted to do that, but I have a high degree of confidence that we can produce something usable and useful without going that far.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Sure, interested parties will try to integrate it once we have early<br>
versions of it, but that still increase the feedback cycle on our<br>
API/architecture hypotheses.<br></blockquote><div><br></div><div>I could shorten that feedback cycle if folks would do code reviews for the outstanding items at <a href="https://review.stackforge.org/#/q/status:open+project:stackforge/ceilometer,n,z">https://review.stackforge.org/#/q/status:open+project:stackforge/ceilometer,n,z</a> so I could stand up a copy of what has already been implemented. ;-)</div>
<div><br></div><div>In all seriousness, it seems reasonable for us to concentrate on the front-end pieces (collecting and storing) for this release, and build a "good enough" API service to retrieve data. Even if that means I end up having to retrieve all of the raw records and process them myself, I can still get my project done as a proof of concept and we can refine the API as we go along using the experience I (and others) gain this time around.</div>
<div><br></div><div>Doug</div><div><br></div></div>