Hi, The whole API discussion made me wondered if this part of the architecture is worth keeping.
The main use case for the metering API is so that billing systems can be integrated in OpenStack. We have the assumption that any billing system will need an integation layer. I think this is a fair assumption. But at the same time, we are forcing the integration to be made around a polling model. From time to time, poll the metering API to create billing artefacts. I'm now of the opinion that we exclude storage and API from the metering project scope. Let's just focus on defining a metering message format, bus, and maybe a client-library to make it easy to write metering consumers. That way we avoid building a lot of things that we only _think will be useful_ for potential billing integration. Only writing/delivering such an integration component would prove that we built at least something that is useful. 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
