<br><br><div class="gmail_quote">On Mon, Sep 10, 2012 at 12:18 PM, Justin Simms <span dir="ltr"><<a href="mailto:justin.simms@gmail.com" target="_blank">justin.simms@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi.<br><br>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. <br><br>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. <br>
</blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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 instantiated).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.</blockquote>
<div><br></div><div>Thanks for volunteering to work on this, Justin!</div><div><br></div><div>Doug</div><div> </div></div>