+1<br><br><div class="gmail_quote">On Wed, May 16, 2012 at 2:00 PM, Francis J. Lacoste <span dir="ltr"><<a href="mailto:francis.lacoste@canonical.com" target="_blank">francis.lacoste@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
The whole API discussion made me wondered if this part of the<br>
architecture is worth keeping.<br>
<br>
The main use case for the metering API is so that billing systems can be<br>
integrated in OpenStack. We have the assumption that any billing system<br>
will need an integation layer. I think this is a fair assumption.<br>
<br>
But at the same time, we are forcing the integration to be made around a<br>
polling model. From time to time, poll the metering API to create<br>
billing artefacts.<br>
<br>
I'm now of the opinion that we exclude storage and API from the metering<br>
project scope. Let's just focus on defining a metering message format,<br>
bus, and maybe a client-library to make it easy to write metering consumers.<br>
<br>
That way we avoid building a lot of things that we only _think will be<br>
useful_ for potential billing integration. Only writing/delivering such<br>
an integration component would prove that we built at least something<br>
that is useful.<br>
<br>
Cheers<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Francis J. Lacoste<br>
<a href="mailto:francis.lacoste@canonical.com">francis.lacoste@canonical.com</a><br>
<br>
</font></span><br>_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br></blockquote></div><br>