The sensu purge_config option now removes rpm deployed plugins

[jaxxstorm]

The change in #302 has broken a use case in which we deploy the plugins separately via an RPM. The original change in that PR called for a separate config value which I personally believe is the right way to go - config and plugins can often be managed separately and this change means this is now not possible.

[jlambert121]

I didn't notice purge was added to plugins as well, I agree that shouldn't have been there. I was afraid getting lots of various purge_* settings which would cause more confusion than benefit. What's your thought of just pulling the purge off of the plugins dir? Or is reverting to multiple purge settings desired? With multiple, should we go all the way and add a purge config setting for each managed directory (or maybe an array of directories to purge?)

[jaxxstorm]

The original PR states that the change will remove plugins, so I'm not surprised this happened. I think the original requester, @nhinds, even stated that purge_config seems to him to be more for JSON configuration. We use the puppet module to manage the JSON, but we manage the code (plugins, handlers, extensions) separately using RPM's we deploy. I think adding separate options (purge_plugin) and setting them to false by default should be sufficient.

[nhinds]

Separate options for each (purge_plugins, purge_handlers, etc.) would make package.pp messier (the combined "ensure all these directories exist" resource would need to be split out), but it's doable.

Alternatively we could migrate to a single enum-like setting, e.g. purge => false, purge => config, purge => all? Possibly keeping the purge_config => true flag as an alias for purge => config if you want to maintain backwards compatibility, or remove it entirely to avoid confusion.

[jaxxstorm]

I think what @nhinds recommends is the best way forward

[jamtur01]

I am unfussed.

[jlambert121]

This was reverted (and re-added as a separate parameter)