ldmsd_set_register/deregister and plugin_sets are inconsistently used

[Tom Tucker]

The plugin_sets configuration request and command were added to allow an administrator to determine the provenance of metrics sets, i.e. which plugins created which metric sets. In support of this effort the ldmsd_set_register and ldmsd_set_deregister API were created to allow a plugin to "tell" ldmsd that they were the creator of a given metric set. In order for the plugin_sets command to report correct results, plugins must call ldmsd_set_register when creating a set and ldmsd_set_deregister when destroying a set. Unfortunately, this has not been done consistently (some don't register at all, and some register, but fail to deregister) and therefore the plugin_sets command reports data that is not always correct. There is no crash risk because the information created by the ldmsd_set_register call does not reference the set or the plugin, it maintains copies of the set name and plugin name strings in a tree.

It is recommended that either we:

• deprecate the plugin_sets configuration request and the associated ldmsd_set_register/deregister API, or we
• create a new API that makes it more difficult to fail to manage registration correctly.

If the later is chosen, it is recommended that new API ldmsd_plugin_set_new and ldmsd_plugin_set_destroy be created and that all the calls in sampler plugins that create and destroy sets use these interfaces instead of ldm_set_new/delete.

[Tom Tucker]

@morrone, this issue is inspired by your observation that the API were not documented.

[Christopher J. Morrone]

Either way, we would need to find a new place to set the sampler update hint (that happens under ldmsd_set_register).