[openstack-dev] [metering] add self- enable/disable check on plugin load

Doug Hellmann doug.hellmann at dreamhost.com
Mon Sep 10 16:43:17 UTC 2012

On Mon, Sep 10, 2012 at 12:18 PM, Justin Simms <justin.simms at gmail.com>wrote:

> Hi.
> I would like to work on an implementation for this wishlist item. I
> thought that I would explain my approach and then get feedback from the
> group.
> Basically, I would like to implement an approach for
> self-enabling/disabling for plugins using explicit disable via config files
> or through the use of a combination of stevedore with a provided
> initialization function for each plugin that will use the environment of
> the system to determine whether or not it needs to disable its polling
> feature, so that for instance a libvirt plugin that is not on a system
> where libvirt is being used would disable itself if it has not been
> explicitly disabled via a config file supplied with ceilometer where each
> plugin has a section with something like a poll-disable , listen-disable,
> or similarly named collection of booleans that would explicitly cut off
> features that were not needed or desired.

There are two overlapping cases that need to be addressed: Disabling a
plugin because it depends on features or libraries not configured within
the current deployment of OpenStack and disabling a plugin because the
deployer chooses not to use it.

The bug describes a case where a plugin knows that it should not be polled
(the libvirt case Justin mentions above). We could handle that in a couple
of ways. One way would be to have the plugin do the check internally and
then just return no counters when it is polled. The runtime inefficiencies
aren't bad, but every new pollster author has to know to handle the case
implicitly. Another way to do it would be to extend the plugin API with a
method that would respond to the question "should you be enabled." The code
that loads the plugin would invoke that method one time, right after
loading, to give the plugin a chance to report that it should not be used.

The config options are meant to handle the case where a deployer wants to
change which counters are being measured. We should use the
openstack.common.cfg configuration code we're already using elsewhere,
rather than add a new file. I think we just need a single option for each
type of plugin ("disabled_pollsters", "disabled_listeners", etc.) where the
value of the configuration setting would be a comma-separated list of
plugin names. The name of each plugin would be checked against the list
from the config option before it is loaded, and disabled plugins would not
be loaded (the code might be imported, but the plugin wouldn't be

I talked a bit with doug about this and we thought it would be better to
> direct this dicsussion to the mailing list. Please let me know your thought
> and/or concerns so that I can do everything I need to so that this feature
> can be implemented appropriately for ceilometer. Thanks.

Thanks for volunteering to work on this, Justin!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120910/94a9ee9a/attachment.html>

More information about the OpenStack-dev mailing list