So let me summarize it:

We have come to agreement in those questions:

1) SSH Soft Fencing logic should be extracted from VdsNotRespondingTreatment
   command to its own SshSoftFencingCommand

2) VdsNotRespondingCommand should be refactored so it's not inherited from
   VdsRestartCommand, but it should run SshSoftFencingCommand
   or VdsRestartCommand based on defined fencing flow


These questions has not been resolved yet:

3) Should SSH Soft Fencing be executed also for hosts without PM configured?

4) Should SSH Soft Fencing execution for hosts without PM configured be enabled
   by default and admin can turn off these feature using configuration options
   SshSoftFencingWithoutPmEnabled (or something like that)?

5) Should SshSoftFencingWithoutPmEnabled be a global option or a cluster wide
   option (can be turned off for specific cluster version) or a VDS option
   (it can be turned off for each host)?


Personally I would suggest:

 ad 3) Yes, SSH Soft Fencing should be executed also for hosts without PM 
configured

 ad 4) Yes, SSH Soft Fencing for hosts without PM configured should be enabled 
by default

 ad 5) I don't see any significant reason why someone would like to turn off 
SSH Soft Fencing
       for hosts without PM configured. But if someone would like to do that, I 
think
       he would like to turn it off only for specific hosts, so VDS level 
option makes sense
       for me


Martin
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Reply via email to