Description of problem: editing a configuration should keep the server plugin enabled if it was already enabled. if we fix this, we have to add scanning code to the server so the server knows if it needs to reload a plugin if another server in the cluster changed a plugin configuration. How reproducible: start two RHQ servers. change a server plugin's configuration, where that server plugin was already enabled. Actual results: the plugin is flipped to disabled. you have to wait for all servers to detect the disablement before you can reenable the plugins in order to pick up the config changes. Expected results: change the config, plugin is reloaded and stays enabled, all servers in the cloud know they need to reload the plugin.
see https://bugzilla.redhat.com/show_bug.cgi?id=559160 Instead of each server disabling a plugin when a configuration changes, I think we should add a "marker" in the plugin configuration so the server just checks that and if it sees that the plugin configuration is different than the one it has, then the server should reload the plugin. This could be simple to do - each configuration has a modified time field - we could use this and have each master server plugin container (or perhaps the server plugin scanner) remember the timestamp of each of its plugins' configurations. If a new configuration is detected (during its normal 5 min scan), then the master plugin container should reload the plugin, but yet retaining its original enable/disable state.
this is now fixed in master: 987ee2cf875b01c80d4ff671d1a5abf154042529 When changing plugin config, the plugin remains in its current state (if it was enabled, it stays enabled). If a plugin was enabled, it will be restarted so it can pick up the latest configuration changes. To test: 1) start server 2) navigate to the server plugin list page and pick any server side plugin that has configuration AND is currently enabled 3) navigate to the chose plugin's configuration page 4) change its configuration and save it 5) go back to the plugin list page and verify that the server plugin is STILL in the enabled state 6) look in the server log and verify that the plugin was reloaded (you'll see messages about the plugin getting initialized/loaded - if you use the /etc/samples/custom-serverplugin sample plugin, you'll see messages prefixed with [STDOUT] showing that it got stopped, re-initialized, and re-started. a second test is required to verify that this works in HA mode: 1) install and start 2 RHQ servers 2) follow the same steps 2-5 above 3) wait a few minutes (depending on how the server is configured - by default, a dev build should not wait longer than 30s, production build no more than 5min) 4) look in the server log for the same kinds of messages you saw on step 6 in the first test above. That second test should show that the second server noticed the configuration changed for a particular plugin and therefore will know that it should reload that plugin so it picks up the new config. NOTE: the two server machines must have their clocks synced - if the times are off, this second test might not work. All RHQ machines must have their clocks synced - this is yet another reason for that to be so (among other reasons).
QA Verified.
Mass-closure of verified bugs against JON.