On Wed, Jan 8, 2014 at 2:08 PM, Tim Bell <tim.b...@cern.ch> wrote: > > > Thanks for the clarifications. Given the role descriptions as provided, I > no longer think there is a need for an API call or per project meter > enable/disable. Thus, the inotify approach would seem to be viable (and > much simpler to implement since the state is clearly defined across daemon > restarts) > Good, thanks, Tim.
Doug > > > Tim > > > > > > *From:* Doug Hellmann [mailto:doug.hellm...@dreamhost.com] > *Sent:* 08 January 2014 19:27 > > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer > > > > > > > > On Wed, Jan 8, 2014 at 12:35 PM, Ildikó Váncsa <ildiko.van...@ericsson.com> > wrote: > > Hi Doug, > > > > Answers inline again. > > > > Best Regards, > > Ildiko > > > > On Wed, Jan 8, 2014 at 3:16 AM, Ildikó Váncsa <ildiko.van...@ericsson.com> > wrote: > > Hi, > > I've started to work on the idea of supporting a kind of tenant/project > based configuration for Ceilometer. Unfortunately I haven't reached the > point of having a blueprint that could be registered until now. I do not > have a deep knowledge about the collector and compute agent services, but > this feature would require some deep changes for sure. Currently there are > pipelines for data collection and transformation, where the counters can be > specified, about which data should be collected and also the time interval > for data collection and so on. These pipelines can be configured now > globally in the pipeline.yaml file, which is stored right next to the > Ceilometer configuration files. > > > > Yes, the data collection was designed to be configured and controlled by > the deployer, not the tenant. What benefits do we gain by giving that > control to the tenant? > > > > ildikov: Sorry, my explanation was not clear. I meant there the > configuration of data collection for projects, what was mentioned by Tim > Bell in a previous email. This would mean that the project administrator is > able to create a data collection configuration for his/her own project, > which will not affect the other project’s configuration. The tenant would > be able to specify meters (enabled/disable based on which ones are needed) > for the given project also with project specific time intervals, etc. > > > > OK, I think some of the confusion is terminology. Who is a "project > administrator"? Is that someone with access to change ceilometer's > configuration file directly? Someone with a particular role using the API? > Or something else? > > > > ildikov: As project administrator I meant a user with particular role, a > user assigned to a tenant. > > > > 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? > > > > In my view, we could keep the dynamic meter configuration bp with > considering to extend it to dynamic configuration of Ceilometer, not just > the meters and we could have a separate bp for the project based > configuration of meters. > > > > Ceilometer uses oslo.config, just like all of the rest of OpenStack. How > are the needs for dynamic configuration updates in ceilometer different > from the other services? > > > > ildikov: There are some parameters in the configuration file of > Ceilometer, like log options and notification types, which would be good to > be able to configure them dynamically. I just wanted to reflect to that > need. As I see, there are two options here. The first one is to identify > the group of the dynamically modifiable parameters and move them to the API > level. The other option could be to make some modifications in oslo.config > too, so other services also could use the benefits of dynamic > configuration. For example the log settings could be a good candidate, as > for example the change of log levels, without service restart, in case > debugging the system can be a useful feature for all of the OpenStack > services. > > > > I "misspoke" earlier. If we're talking about meters, those are actually > defined by the pipeline file (not oslo.config). So if we do want that file > re-read automatically, we can implement that within ceilometer itself, > though I'm still reluctant to say we want to provide API access for > modifying those settings. That's *really* not something we've designed the > rest of the system to accommodate, so I don't know what side-effects we > might introduce. > > > > ildikov: In case of oslo.config, I meant the ceilometer.conf file in my > answer above, not pipeline.yaml. As for the API part, I do not know the > consequences of that implementation either, so now I’m kind of waiting for > the outcome of this Dynamic Meters bp. > > > > As far as the other configuration settings, we had the conversation about > updating those through some sort of API early on, and decided that there > are already lots of operational tools out there to manage changes to those > files. I would need to see a list of which options people would want to > have changed through an API to comment further. > > > > ildikov: Yes, I agree that not all the parameters should be configured > dynamically. It just popped into my mind regarding the dynamic > configuration, that there would be a need to configure other configuration > parameters, not just meters, that is why I mentioned it as a considerable > item. > > > > OK. > > > > > > > > Doug > > > > > > > > Doug > > > > > > > If it is ok for you, I will register the bp for this per-project tenant > settings with some details, when I'm finished with the initial design of > how this feature could work. > > Best Regards, > Ildiko > > > -----Original Message----- > From: Neal, Phil [mailto:phil.n...@hp.com] > Sent: Tuesday, January 07, 2014 11:50 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer > > For multi-node deployments, implementing something like inotify would > allow administrators to push configuration changes out to multiple targets > using puppet/chef/etc. and have the daemons pick it up without restart. > Thumbs up to that. > > As Tim Bell suggested, API-based enabling/disabling would allow users to > update meters via script, but then there's the question of how to work out > the global vs. per-project tenant settings...right now we collect specified > meters for all available projects, and the API returns whatever data is > stored minus filtered values. Maybe I'm missing something in the > suggestion, but turning off collection for an individual project seems like > it'd require some deep changes. > > Vijay, I'll repeat dhellmann's request: do you have more detail in another > doc? :-) > > - Phil > > > -----Original Message----- > > From: Kodam, Vijayakumar (EXT-Tata Consultancy Ser - FI/Espoo) > > [mailto:vijayakumar.kodam....@nsn.com] > > Sent: Tuesday, January 07, 2014 2:49 AM > > To: OpenStack Development Mailing List (not for usage questions) > > Cc: chmo...@enovance.com > > Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer > > From: ext Chmouel Boudjnah [mailto:chmo...@enovance.com] > > Sent: Monday, January 06, 2014 2:19 PM > > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer > > > > > > > > > > > > On Mon, Jan 6, 2014 at 12:52 PM, Kodam, Vijayakumar (EXT-Tata > > Consultancy Ser - FI/Espoo) <vijayakumar.kodam....@nsn.com> wrote: > > > > In this case, simply changing the meter properties in a configuration > > file should be enough. There should be an inotify signal which shall > > notify ceilometer of the changes in the config file. Then ceilometer > > should automatically update the meters without restarting. > > > > > > > > Why it cannot be something configured by the admin with inotifywait(1) > > command? > > > > > > > > Or this can be an API call for enabling/disabling meters which could > > be more useful without having to change the config files. > > > > > > > > Chmouel. > > > > > > > > I haven't tried inotifywait() in this implementation. I need to check > > if it will be useful for the current implementation. > > > > Yes. API call could be more useful than changing the config files > manually. > > > > > > > > Thanks, > > > > VijayKumar > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev