Just moving a private discussion to the list. For more comments.
The screenshot is at
The actual idea is to add small links (like buttons) to do the operations:
enable/stop/disable on a context. (disable means no new session (a new
session is request without sessionid) and enable means re-enable a
stopped or disabled context.
start/stop/enable/disable on node.
That corresponds to the mod_jk concept (active/disable/stop). We can't
start or stop a node from httpd because the node should be discovered
automatically and administered in the cluster.
But in the mod_cluster logic a disabled node is just a node with all its
contexts disabled and a stop node corresponds to all contexts stopped.
I would proposed links that do the following:
disable node = disable all contexts of node.
stop node = stop all contexts of node.
activate node = restore the state the cluster has sent to httpd
Of course all those actions are undone by restarting a node or the
webapp in the cluster.
Bela Ban wrote:
jean-frederic clere wrote:
> Now I have a "nice" status page.
Excellent, looks good !
> I am still thinking about the part:
> - allow a user to disable/enable a web app
> - start/stop/enable/disable a cluster node
> Will this bring more problems that help?
OK, we should at least have the *same* functionality we have for mod-jk
and the /status/ app. We *can* enable/stop/disable workers with /status/.
Let's leave enabling/disabling of webapps out for now.
In fact the logic in context = webapps and it is already there it just
need a simple extension.
> Because any change of topology in the cluster nodes will of course
> overwrite the user action. Are you sure we need something like that?
I think that's fine.
> For example:
> 1 - The user in httpd disable an application.
> 2 - The application is redeployed on that node: that means it is
> removed at some point in the logic and created again. When it is
> created again we have lost the information that it was disabled by the
> httpd user.
> 3 - The user will seen the application "magically" enable again.
That's the behavior I'd expect
> That looks logic for me but I am not sure it won't give complains in
> Comments? - May I should just have "temporarily" in front of the
> disable/enable/start/stop (and start/stop needs another wording) -
Can we discuss this on the mod-cluster mailing list ? I'm sure you'll
get more valuable input there...