On Fri, May 18, 2012 at 4:53 PM, Francis J. Lacoste < [email protected]> wrote:
> On 12-05-18 05:27 AM, Thierry Carrez wrote: > > 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 :) > > Right, I like this approach very much. > > The main thing I'm worried about is that we are building a system that > has no use in _itself_. It's all about enabling integration in > third-party billing system, but we aren't building such an integration > as part of this project. > 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. > We could easily implement something that lacks our focus. Maybe, that's > an argument for building a simple billing app as part of OpenStack as a > proof of concept that the metering system can be integrated. > 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. > > Sure, interested parties will try to integrate it once we have early > versions of it, but that still increase the feedback cycle on our > API/architecture hypotheses. > I could shorten that feedback cycle if folks would do code reviews for the outstanding items at https://review.stackforge.org/#/q/status:open+project:stackforge/ceilometer,n,zso I could stand up a copy of what has already been implemented. ;-) 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. Doug
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
