Re: [Engine-devel] SSH Soft Fencing

From: "Livnat Peer" <lpeer(a)redhat.com&gt; To: "Yair Zaslavsky" <yzaslavs(a)redhat.com&gt; Cc: engine-devel(a)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(a)redhat.com&gt; >> To: engine-devel(a)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.

>> >> >> Martin >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel