<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 8, 2014 at 2:08 PM, Tim Bell <span dir="ltr"><<a href="mailto:Tim.Bell@cern.ch" target="_blank">Tim.Bell@cern.ch</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-GB" link="blue" vlink="purple">
<div>
<p><u></u> <u></u></p>
<p>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)</p></div></div></blockquote><div><div class="gmail_default" style="font-size:small">Good, thanks, Tim.</div><div class="gmail_default" style="font-size:small">
<br></div><div class="gmail_default" style="font-size:small">Doug</div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple">
<div><p><u></u><u></u></p>
<p><u></u> <u></u></p>
<p>Tim<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif""> Doug Hellmann [mailto:<a href="mailto:doug.hellmann@dreamhost.com" target="_blank">doug.hellmann@dreamhost.com</a>]
<br>
<b>Sent:</b> 08 January 2014 19:27</span></p><div><div class="h5"><br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer<u></u><u></u></div></div><p></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Wed, Jan 8, 2014 at 12:35 PM, Ildikó Váncsa <<a href="mailto:ildiko.vancsa@ericsson.com" target="_blank">ildiko.vancsa@ericsson.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi Doug,</span><span lang="EN-US"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><span lang="EN-US"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Answers inline again.</span><span lang="EN-US"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><span lang="EN-US"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Best Regards,</span><span lang="EN-US"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Ildiko</span><span lang="EN-US"><u></u><u></u></span></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"> <u></u><u></u></span></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">On Wed, Jan 8, 2014 at 3:16 AM, Ildikó Váncsa <<a href="mailto:ildiko.vancsa@ericsson.com" target="_blank">ildiko.vancsa@ericsson.com</a>> wrote:<u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">Hi,<br>
<br>
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.<u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">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?<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><span lang="EN-US"><u></u><u></u></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.</span><span lang="EN-US"><u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">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?<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><span lang="EN-US"><u></u><u></u></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">ildikov: As project administrator I meant a user with particular role, a user assigned
 to a tenant.</span><span lang="EN-US"><u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>

</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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?<u></u><u></u></p>

</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<div>
<div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<p class="MsoNormal"><span lang="EN-US">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.<u></u><u></u></span></p>
</blockquote>
<div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">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?<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><span lang="EN-US"><u></u><u></u></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.</span><span lang="EN-US"><u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><span lang="EN-US"><u></u><u></u></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.</span><span lang="EN-US"><u></u><u></u></span></p>

</div>
<div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><span lang="EN-US"><u></u><u></u></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.</span><span lang="EN-US"><u></u><u></u></span></p>

</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal">OK.<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Doug<u></u><u></u></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Doug<u></u><u></u></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<p class="MsoNormal"><span lang="EN-US"><br>
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.<br>
<br>
Best Regards,<br>
Ildiko<u></u><u></u></span></p>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"><br>
-----Original Message-----<br>
From: Neal, Phil [mailto:<a href="mailto:phil.neal@hp.com" target="_blank">phil.neal@hp.com</a>]<br>
Sent: Tuesday, January 07, 2014 11:50 PM<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer<br>
<br>
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.<br>

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

<br>
Vijay, I'll repeat dhellmann's request: do you have more detail in another doc? :-)<br>
<br>
-       Phil<br>
<br>
> -----Original Message-----<br>
> From: Kodam, Vijayakumar (EXT-Tata Consultancy Ser - FI/Espoo)<br>
> [mailto:<a href="mailto:vijayakumar.kodam.ext@nsn.com" target="_blank">vijayakumar.kodam.ext@nsn.com</a>]<br>
> Sent: Tuesday, January 07, 2014 2:49 AM<br>
> To: OpenStack Development Mailing List (not for usage questions)<br>
> Cc: <a href="mailto:chmouel@enovance.com" target="_blank">chmouel@enovance.com</a><br>
> Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer<br>
> From: ext Chmouel Boudjnah [mailto:<a href="mailto:chmouel@enovance.com" target="_blank">chmouel@enovance.com</a>]<br>
> Sent: Monday, January 06, 2014 2:19 PM<br>
> To: OpenStack Development Mailing List (not for usage questions)<br>
> Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer<br>
><br>
><br>
><br>
><br>
><br>
> On Mon, Jan 6, 2014 at 12:52 PM, Kodam, Vijayakumar (EXT-Tata<br>
> Consultancy Ser - FI/Espoo) <<a href="mailto:vijayakumar.kodam.ext@nsn.com" target="_blank">vijayakumar.kodam.ext@nsn.com</a>> wrote:<br>
><br>
> In this case, simply changing the meter properties in a configuration<br>
> file should be enough. There should be an inotify signal which shall<br>
> notify ceilometer of the changes in the config file. Then ceilometer<br>
> should automatically update the meters without restarting.<br>
><br>
><br>
><br>
> Why it cannot be something configured by the admin with inotifywait(1)<br>
> command?<br>
><br>
><br>
><br>
> Or this can be an API call for enabling/disabling meters which could<br>
> be more useful without having to change the config files.<br>
><br>
><br>
><br>
> Chmouel.<br>
><br>
><br>
><br>
> I haven't tried inotifywait() in this implementation. I need to check<br>
> if it will be useful for the current implementation.<br>
><br>
> Yes. API call could be more useful than changing the config files manually.<br>
><br>
><br>
><br>
> Thanks,<br>
><br>
> VijayKumar<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><u></u><u></u></span></p>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><u></u><u></u></span></p>
</blockquote>
</div>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div></div></div>
</div>
</div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>