Bug 559160 - Server Side plugin config should have "enable" button
Summary: Server Side plugin config should have "enable" button
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: RHQ Project
Classification: Other
Component: Core UI
Version: 1.3
Hardware: All
OS: Linux
low
low
Target Milestone: ---
: ---
Assignee: John Mazzitelli
QA Contact: Corey Welton
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-01-27 10:23 UTC by Heiko W. Rupp
Modified: 2010-03-25 14:16 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-03-25 14:16:14 UTC
Embargoed:


Attachments (Terms of Use)

Description Heiko W. Rupp 2010-01-27 10:23:57 UTC
Description of problem:

When editing a plugin configuration of a server side plugin, the plugin is disabled (which I think is wrong anyway).
Problem: 
- the user gets no notification of this on the plugin config screen
- it takes many clicks in the UI to go to the point to re-enable the plugin

So: 
- user needs a message about the plugin being disabled
- a re-enable button or direct link to the server side plugins should be given on the config page.

Comment 1 John Mazzitelli 2010-01-28 15:20:46 UTC
> When editing a plugin configuration of a server side plugin,
> the plugin is disabled (which I think is wrong anyway).

I'll explain why this is.

First, if you have only a single server (i.e. you are not using multiple RHQ Servers in an HA Server Cloud), then yes this is not needed - we should just reload the plugin in the same state it was in (if it was disabled, leave disabled; if enabled, leave enabled). In fact, that could be an enhancement we should make - if there is only one server in the RHQ_SERVER table, then we should not disable the plugin.

But - think about the case when there is 2 or more RHQ Servers in the HA Server Cloud. Let's go through an example.

I have 2 RHQ Servers, server #1 and server #2. Each, of course, has their own set of server-side plugins running in their own master plugin container. As with everything else in our homogenous design, these 2 RHQ Server master plugin containers are independent of one another - they don't directly talk to each other, they don't know each other exists.

I point my browser to server #1 and through its GUI, I change a server plugin's configuration, persisting the change to the database. Server #1 knows the change was made - because I made the change through its GUI. So Server #1 knows enough to tell its master plugin container that it needs to reload the plugin whose configuration changed. *BUT!* How does server #2 know that this plugin's configuration changed? How does it need to know that it must get its master plugin container to reload the plugin? There is no way today for this to happen, short of the servers to periodically poll the database.

How do we solve this today? When a server changes a plugin configuration (like I did on server #1 in the above example), the server will disable the plugin. By default, all servers check into the database every 5 minutes to see if a plugin state changed (enabled->disabled, or disabled->enabled) and reloads the plugins as appropriate (see org.rhq.enterprise.server.core.plugin.ServerPluginScanner.registerServerPlugins()). So, in effect, this change to the disabled state IS the communication from one server to all others in the HA Server - its how one server lets the others know that they need to reload the plugin because its configuration changed.

This is not a good solution because it means to be absolutely sure all servers pick up a config change, the user must not re-enable a plugin for at least 5 minutes after a plugin config change was made. What we need to do is have each server periodically poll the plugin configuration as seen in the database and if a change has been detected, then it should reload its plugin (this would allow the state to remain as-is since the state value will not be used as the "change marker".

Comment 2 John Mazzitelli 2010-01-28 15:24:19 UTC
I think the scope of this BZ should be expanded to include the change in the way servers detect plugin configuration changes.

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.

Comment 3 John Mazzitelli 2010-01-28 15:48:53 UTC
opps... there is already a BZ for what I want to do:

https://bugzilla.redhat.com/show_bug.cgi?id=548526

"changing a server plugin configuration should keep enabled state but work across ha server cloud"

if we fix that, this need for an enable button should be low severity.

Comment 4 John Mazzitelli 2010-01-29 08:12:28 UTC
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.

Because of this change, I think this issue can be closed as "Obsolete".

Heiko - would you agree? Now that changing plugin configuration no longer disables the plugin, I don't think we need to do what this bugzilla is asking to do.

Comment 5 Corey Welton 2010-03-25 14:16:14 UTC
QA Closing per Comment #4


Note You need to log in before you can comment on or make changes to this bug.