Open Stack

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.

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.

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.

Cheers

-- 
Francis J. Lacoste
francis.lacoste at canonical.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120518/1d421c49/attachment.sig>