<br><br><div class="gmail_quote">On Fri, May 4, 2012 at 12:29 PM, Nick Barcet <span dir="ltr"><<a href="mailto:nick.barcet@canonical.com" target="_blank">nick.barcet@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Following up on the discussion on IRC yesterday during the metering meeting, I'd like to explain my proposal to add the notion of source to the schema of our event.  The current goal we have for ceilometer is to provide a common way to accumulate counters/meters from various openstack component in a central repository that can be then used by other tools to produce bills in fine.   One thing we can currently assume in Essex is that all components share a common repository for identity management: Keystone.  This is the assumption we made when defining the existing schema. However, I think we need to plan a little further ahead here, and allow for this not to necessarily remain the same in some complex deployment cases.<br>

<br>
For example, it could be envisioned that some software, outside of the OpenStack project, maybe deployed and used on top of an OpenStack deployment.  This software may need to be billed to customers, and collecting meters for it maybe as important for the provider than doing it for OpenStack components. It cannot be assumed that the identity management used by  the software will be keystone. The software may not provide a metering interface built in, and it would make sense for the provider to be able to implement this using existing tool present in the underlying OpenStack deployment: ceilometer. <br>

<br>
In order to allow for this I think it would make sense to:<br>
* extend the current schema to allow for an additional "source" field in the event record.  This should be a short identifier.<br></blockquote><div><br></div><div>That makes sense. It seems like the identifier(s) used are meant to be defined by the deployer. Is that your intent?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* add another record definition that maps source to identity managment URL location<br>
* Collecting agent would be in charge to specify the source they map to (keystone by default). <br></blockquote><div><br></div><div>It is not clear why the identity management location needs to be recorded in ceilometer. If the deployer controls the source strings, they know what each value means. The only thing that needs to translate the (source, project, user) values to a billing identity is the end-consumer of all of this data, which is also under the control of the deployer. Couldn't the mapping of the source token to the identity location be handled in that layer?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think this would allow for easy extension of ceilometer to support other software, but I'd like to know if you share the usefulness of this extension from your experiences.<br>
<br>
Thanks,<br>
<br>
Nick<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>
</blockquote></div><br>