Open Stack

Hi Doug,
OK, so like I said, we did not design the system with the idea that a user of the cloud (rather than the deployer of the cloud) would have any control over what data was collected. They can ask questions about only some of the data, but they can't tell ceilometer what to collect.

There's a certain amount of danger in giving the cloud user (no matter their role) an "off switch" for the data collection. As Julien pointed out, it can have a negative effect on billing -- if they tell the cloud not to collect data about what instances are created, then the deployer can't bill for those instances. Differentiating between the values that always must be collected and the ones the user can control makes providing an API to manage data collection more complex.

Is there some underlying use case behind all of this that someone could describe in more detail, so we might be able to find an alternative, or explain how to use the existing features to achieve the goal? For example, it is already possible to change the pipeline config file to control which data is collected and stored. If we make the pipeline code in ceilometer watch for changes to that file, and rebuild the pipelines when the config is updated, would that satisfy the requirements?

ildikov: Thanks for the clarification. The base idea was to provide the possibility of different data collection configuration for projects. Reflecting to the dynamic meter configuration and the possible API based solution, it seemed to be possible to provide the configuration possibility to the users of the cloud as well. At this point, I haven't considered the billing aspect, which would be affected by this extra option, as you mentioned it above, so it was definitely a wrong direction. Finally we've reached a consensus with Julien by making the required changes in pipeline.yaml and the related codebase.

ildikov: Thanks to both of you for the effort in clarifying this.

Best Regards,
Ildiko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140108/d0a92803/attachment.html>