On Jul 2, 2013, at 10:44 , Eli Mesika <emesika@redhat.com> wrote:
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: engine-devel@ovirt.org Sent: Monday, July 1, 2013 12:57:34 PM Subject: Re: [Engine-devel] SSH Soft Fencing
On 07/01/2013 11:27 AM, Yair Zaslavsky wrote:
----- Original Message -----
From: "Martin Perina" <mperina@redhat.com> To: engine-devel@ovirt.org Sent: Monday, July 1, 2013 11:23:12 AM Subject: Re: [Engine-devel] SSH Soft Fencing
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
+1
ad 4) Yes, SSH Soft Fencing for hosts without PM configured should be enabled by default
+1
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
After re-thinking 5 - I agree. +1 on the other suggestions, but of course we need to get more consensus here.
I think it does not need to be configurable.
I think a configuration option, as cumbersome and confusing as it can be, is still better than no choice. Especially if it means to restore the previous behavior. If it only can happen in a theoretical problem at customer where vdsm restart cause issues for whatever theoretical reason….it would be of great help then. And if you don't understand the parameter - just don't touch it, I hope that's a general rule:-)
+1 on all above as well
Martin _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel