openstack team mailing list archive

[Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx>]

On Fri, May 18, 2012 at 4:53 PM, Francis J. Lacoste <
francis.lacoste@xxxxxxxxxxxxx> 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