Hi, >-----Original Message----- >From: ext Neal, Phil [mailto:phil.n...@hp.com] >Sent: Wednesday, January 08, 2014 12:50 AM >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. >
Thanks! >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 I concur with the opinion to use APIs for dynamically enabling/disabling meters. I have updated the design accordingly. According to the latest update: User calls the API(1) to disable a meter along with a meter id. Ceilometer-api handles the api request, adds the meter id to disabled_meters config file and informs ceilometer agents. Ceilometer agents will read the "disabled_meters" config file and disables the meter. More detailed information about this blueprint can be found at https://etherpad.openstack.org/p/dynamic-meters There will be no inotify() or inotifywait() calls to monitor the modifications of the configuration file. Whenever the APIs are called, ceilometer-api upon receiving the request, will modify the config file and informs the ceilometer agents. There are no per-project settings currently considered for this blueprint. IMHO, per-project settings should be implemented for all the meters/resources/APIs in ceilometer and should be handled by a different blueprint. Regards, VijayKumar >> -----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
