<br><br><div class="gmail_quote">On Fri, May 4, 2012 at 6:03 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">
<div class="im">On 05/04/2012 02:25 PM, Doug Hellmann wrote:<br>
><br>
><br>
> On Fri, May 4, 2012 at 12:29 PM, Nick Barcet <<a href="mailto:nick.barcet@canonical.com">nick.barcet@canonical.com</a><br>
</div><div><div class="h5">> <mailto:<a href="mailto:nick.barcet@canonical.com">nick.barcet@canonical.com</a>>> wrote:<br>
><br>
> Following up on the discussion on IRC yesterday during the metering<br>
> meeting, I'd like to explain my proposal to add the notion of source<br>
> to the schema of our event. The current goal we have for ceilometer<br>
> is to provide a common way to accumulate counters/meters from<br>
> various openstack component in a central repository that can be then<br>
> used by other tools to produce bills in fine. One thing we can<br>
> currently assume in Essex is that all components share a common<br>
> repository for identity management: Keystone. This is the<br>
> assumption we made when defining the existing schema. However, I<br>
> think we need to plan a little further ahead here, and allow for<br>
> this not to necessarily remain the same in some complex deployment<br>
> cases.<br>
><br>
> For example, it could be envisioned that some software, outside of<br>
> the OpenStack project, maybe deployed and used on top of an<br>
> OpenStack deployment. This software may need to be billed to<br>
> customers, and collecting meters for it maybe as important for the<br>
> provider than doing it for OpenStack components. It cannot be<br>
> assumed that the identity management used by the software will be<br>
> keystone. The software may not provide a metering interface built<br>
> in, and it would make sense for the provider to be able to implement<br>
> this using existing tool present in the underlying OpenStack<br>
> 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"<br>
> field in the event record. This should be a short identifier.<br>
><br>
><br>
> That makes sense. It seems like the identifier(s) used are meant to be<br>
> defined by the deployer. Is that your intent?<br>
<br>
</div></div>Correct. We'll just need a sane default for Keystone.<br></blockquote><div><br></div><div>You're focusing on source as the origin for the identity information, but it seems like a layer sitting on top of OpenStack may well use Keystone for identity but generate different billable events. Should "source" be the origin of the metric data being sent to ceilometer?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
><br>
> * add another record definition that maps source to identity<br>
> managment URL location<br>
> * Collecting agent would be in charge to specify the source they map<br>
> to (keystone by default).<br>
><br>
><br>
> It is not clear why the identity management location needs to be<br>
> recorded in ceilometer. If the deployer controls the source strings,<br>
> they know what each value means. The only thing that needs to translate<br>
> the (source, project, user) values to a billing identity is the<br>
> end-consumer of all of this data, which is also under the control of the<br>
> deployer. Couldn't the mapping of the source token to the identity<br>
> location be handled in that layer?<br>
<br>
</div>True. It might be over-engineering to try to keep the info in the same<br>
place as well, but the impact on the system would be negligible. I'd be<br>
happy either ways :)</blockquote><div><br></div><div>It will be easier to add it later if we really need it than to take it out if we decide we don't.</div><div><br></div><div>Doug</div><div> </div></div>