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 [email protected]
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
