openstack team mailing list archive

[Nick Barcet <nick.barcet@xxxxxxxxxxxxx>]

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>> wrote:
> 
>     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.
> 
>     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. 
> 
>     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.

> 
>     * 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 :)

Nick

Attachment: signature.asc
Description: OpenPGP digital signature