Open Stack

On Fri, May 4, 2012 at 12:29 PM, Nick Barcet <nick.barcet at canonical.com>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?


> * 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?


>
> 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.
>
> Thanks,
>
> Nick
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120504/501c6d08/attachment.html>