On 05/04/2012 03:11 PM, Doug Hellmann wrote: > > > On Fri, May 4, 2012 at 6:03 PM, Nick Barcet <nick.bar...@canonical.com > <mailto:nick.bar...@canonical.com>> wrote: > > On 05/04/2012 02:25 PM, Doug Hellmann wrote: > > > > > > On Fri, May 4, 2012 at 12:29 PM, Nick Barcet > <nick.bar...@canonical.com <mailto:nick.bar...@canonical.com> [...] > > In order to allow for this I think it would make sense to: > > * extend the current schema to allow for an additional "source" > > field in the event record. This should be a short identifier. > > > > > > That makes sense. It seems like the identifier(s) used are meant to be > > defined by the deployer. Is that your intent? > > Correct. We'll just need a sane default for Keystone. > > > 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?
As I see it, source should remain the same as long as you can correlate project_id and user_id from the same source. > > > > * add another record definition that maps source to identity > > managment URL location > > * Collecting agent would be in charge to specify the source > they map > > to (keystone by default). > > > > > > 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? > > True. It might be over-engineering to try to keep the info in the same > place as well, but the impact on the system would be negligible. I'd be > happy either ways :) > > > It will be easier to add it later if we really need it than to take it > out if we decide we don't. Agreed. Nick
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp