Open Stack

On Wed, Jan 8, 2014 at 2:08 PM, Tim Bell <Tim.Bell at 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.hellmann at 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.vancsa at ericsson.com>
> wrote:
>
>  Hi Doug,
>
>
>
> Answers inline again.
>
>
>
> Best Regards,
>
> Ildiko
>
>
>
> On Wed, Jan 8, 2014 at 3:16 AM, Ildikó Váncsa <ildiko.vancsa at 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.neal at 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.ext at nsn.com]
> > Sent: Tuesday, January 07, 2014 2:49 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Cc: chmouel at enovance.com
> > Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer
> > From: ext Chmouel Boudjnah [mailto:chmouel at 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.ext at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140108/92ea2f28/attachment.html>