<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style id="owaParaStyle">P {
MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
</style>
</head>
<body fPStyle="1" ocsi="0">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">
<blockquote style="MARGIN-RIGHT: 0px" dir="ltr">
<p> ><br>
>--------------------------------------------------------------------------------<br>
>From: ext Doug Hellmann [doug.hellmann@dreamhost.com]<br>
>Sent: Wednesday, January 08, 2014 8:26 PM<br>
>To: OpenStack Development Mailing List (not for usage questions)<br>
>Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer<br>
><br>
><br>
>On Wed, Jan 8, 2014 at 12:35 PM, Ildikó Váncsa <<a href="mailto:ildiko.vancsa@ericsson.com">ildiko.vancsa@ericsson.com</a>> wrote:<br>
><br>
>Hi Doug,<br>
><br>
>Answers inline again.<br>
><br>
>Best Regards,<br>
><br>
>Ildiko<br>
><br>
><br>
>On Wed, Jan 8, 2014 at 3:16 AM, Ildikó Váncsa <<a href="mailto:ildiko.vancsa@ericsson.com">ildiko.vancsa@ericsson.com</a>> wrote:<br>
><br>
>Hi,<br>
><br>
>I've started to work on the idea of supporting a kind of tenant/project<br>
> based configuration for Ceilometer. Unfortunately I haven't reached<br>
> the point of having a blueprint that could be registered until now.<br>
> I do not have a deep knowledge about the collector and compute agent<br>
> services, but this feature would require some deep changes for sure.<br>
> Currently there are pipelines for data collection and transformation,<br>
> where the counters can be specified, about which data should be<br>
> collected and also the time interval for data collection and so on.<br>
> These pipelines can be configured now globally in the pipeline.yaml file,<br>
> which is stored right next to the Ceilometer configuration files.<br>
><br>
>Yes, the data collection was designed to be configured and controlled by<br>
> the deployer, not the tenant. What benefits do we gain by giving that<br>
> control to the tenant?<br>
> <br>
>ildikov: Sorry, my explanation was not clear. I meant there the configuration<br>
> of data collection for projects, what was mentioned by Tim Bell in a <br>
> previous email. This would mean that the project administrator is able to <br>
> create a data collection configuration for his/her own project, which will<br>
> not affect the other project’s configuration. The tenant would be able to<br>
> specify meters (enabled/disable based on which ones are needed) for the given<br>
> project also with project specific time intervals, etc.<br>
><br>
>OK, I think some of the confusion is terminology. <br>
>Who is a "project administrator"? Is that someone with access to change<br>
> ceilometer's configuration file directly? Someone with a particular role<br>
> using the API? Or something else?<br>
><br>
>ildikov: As project administrator I meant a user with particular role,<br>
> a user assigned to a tenant.<br>
><br>
><br>
>OK, so like I said, we did not design the system with the idea that a<br>
> user of the cloud (rather than the deployer of the cloud) would have<br>
> any control over what data was collected. They can ask questions about<br>
> only some of the data, but they can't tell ceilometer what to collect.<br>
>There's a certain amount of danger in giving the cloud user<br>
> (no matter their role) an "off switch" for the data collection.<br>
><br>
> As Julien pointed out, it can have a negative effect on billing <br>
> -- if they tell the cloud not to collect data about what instances<br>
> are created, then the deployer can't bill for those instances.<br>
> Differentiating between the values that always must be collected and<br>
> the ones the user can control makes providing an API to manage data<br>
> collection more complex.<br>
> <br>
>Is there some underlying use case behind all of this that someone could<br>
> describe in more detail, so we might be able to find an alternative, or<br>
> explain how to use the existing features to achieve the goal?<br>
><br>
> For example, it is already possible to change the pipeline config file<br>
> to control which data is collected and stored.<br>
> If we make the pipeline code in ceilometer watch for changes to that file,<br>
> and rebuild the pipelines when the config is updated, <br>
> would that satisfy the requirements?<br>
></p>
</blockquote>
<p dir="ltr">Yes. That's exactly the requirement for our blueprint. To avoid ceilometer restart for changes to take effect, when the config file changes.
<br>
API support was added later based on the request in this mail chain. We actually don't need APIs and can be removed.</p>
<p dir="ltr">So as you mentioned above, whenever the config file is changed, ceilometer should update the meters accordingly.</p>
<p dir="ltr"> </p>
<blockquote style="MARGIN-RIGHT: 0px" dir="ltr">
<p> ><br>
> <br>
>In my view, we could keep the dynamic meter configuration bp with considering<br>
> to extend it to dynamic configuration of Ceilometer, not just the meters and<br>
> we could have a separate bp for the project based configuration of meters.<br>
>Ceilometer uses oslo.config, just like all of the rest of OpenStack. How are<br>
> the needs for dynamic configuration updates in ceilometer different from<br>
> the other services?<br>
><br>
><br>
>ildikov: There are some parameters in the configuration file of Ceilometer,<br>
> like log options and notification types, which would be good to be able to<br>
> configure them dynamically. I just wanted to reflect to that need. As I see,<br>
> there are two options here. The first one is to identify the group of the<br>
> dynamically modifiable parameters and move them to the API level. The other<br>
> option could be to make some modifications in oslo.config too, so other<br>
> services also could use the benefits of dynamic configuration. For example<br>
> the log settings could be a good candidate, as for example the change of log<br>
> levels, without service restart, in case debugging the system can be a useful<br>
> feature for all of the OpenStack services.<br>
><br>
>I "misspoke" earlier. If we're talking about meters, those are actually defined<br>
> by the pipeline file (not oslo.config). So if we do want that file re-read<br>
> automatically, we can implement that within ceilometer itself, though I'm still<br>
> reluctant to say we want to provide API access for modifying those settings.<br>
> That's *really* not something we've designed the rest of the system to<br>
> accommodate, so I don't know what side-effects we might introduce.<br>
><br>
>ildikov: In case of oslo.config, I meant the ceilometer.conf file in my<br>
> answer above, not pipeline.yaml. As for the API part, I do not know the<br>
> consequences of that implementation either, so now I’m kind of waiting<br>
> for the outcome of this Dynamic Meters bp.<br>
><br>
>As far as the other configuration settings, we had the conversation about<br>
> updating those through some sort of API early on, and decided that there<br>
> are already lots of operational tools out there to manage changes to those<br>
> files. I would need to see a list of which options people would want to<br>
> have changed through an API to comment further.<br>
><br>
>ildikov: Yes, I agree that not all the parameters should be configured<br>
> dynamically. It just popped into my mind regarding the dynamic configuration,<br>
> that there would be a need to configure other configuration parameters,<br>
> not just meters, that is why I mentioned it as a considerable item.<br>
><br>
>If it is ok for you, I will register the bp for this per-project tenant<br>
> settings with some details, when I'm finished with the initial design<br>
> of how this feature could work.<br>
><br>
>Best Regards,<br>
>Ildiko<br>
><br>
><br>
>-----Original Message-----<br>
>From: Neal, Phil [mailto:phil.neal@hp.com]<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<br>
> administrators to push configuration changes out to multiple targets using<br>
> puppet/chef/etc. and have the daemons pick it up without restart.<br>
> Thumbs up to that.<br>
><br>
>As Tim Bell suggested, API-based enabling/disabling would allow users to<br>
> update meters via script, but then there's the question of how to work out the<br>
> global vs. per-project tenant settings...right now we collect specified meters<br>
> for all available projects, and the API returns whatever data is stored minus<br>
> filtered values. Maybe I'm missing something in the suggestion, but turning off<br>
> 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>
>><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">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>
>> Why it cannot be something configured by the admin with inotifywait(1)<br>
>> command?<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>
>> Chmouel.<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>
>> Thanks,<br>
>><br>
>> VijayKumar<br>
><br>
</p>
</blockquote>
</div>
</body>
</html>