openstack team mailing list archive

[Nick Barcet <nick.barcet@xxxxxxxxxxxxx>]

On 05/04/2012 03:11 PM, Doug Hellmann wrote:
> 
> 
> On Fri, May 4, 2012 at 6:03 PM, Nick Barcet <nick.barcet@xxxxxxxxxxxxx
> <mailto:nick.barcet@xxxxxxxxxxxxx>> wrote:
> 
>     On 05/04/2012 02:25 PM, Doug Hellmann wrote:
>     >
>     >
>     > On Fri, May 4, 2012 at 12:29 PM, Nick Barcet
>     <nick.barcet@xxxxxxxxxxxxx <mailto:nick.barcet@xxxxxxxxxxxxx>
[...]
>     >     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

Attachment: signature.asc
Description: OpenPGP digital signature