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