Re: [Engine-devel] SSH Soft Fencing

From: "Livnat Peer" <lpeer(a)redhat.com&gt; To: "Martin Perina" <mperina(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org Sent: Wednesday, July 3, 2013 2:32:16 PM Subject: Re: [Engine-devel] SSH Soft Fencing Hi Martin, I have some more questions, - Do we persist the host root password for this feature? - If we do, is this feature limited for new hosts, can I provide it for already existing hosts? - Do we encrypt this value when storing in the DB? Thanks, Livnat

On 07/03/2013 02:55 PM, Martin Perina wrote: > Let's summarize again, SSH Soft Fencing patches has been merged yesterday > with following functionality: > > 1) For hosts with power management configured, SSH Soft Fencing is the 1st > fencing stage. If it doesn't help, real fencing will be executed. > > 2) For hosts without power management configured, SSH Soft Fencing is the > only > fencing stage. If it doesn't help, host will become non responsive. > > 3) SSH Soft Fencing is enabled by default, there's no configuration option > to disable it > > 4) SshSoftFencingCommand option is used to define what command is executed > during SSH Soft Fencing. It can only be changed manually in database. > > The whole fencing process in oVirt 3.3 is decribed at > > http://www.ovirt.org/Automatic_Fencing#Automatic_Fencing_in_oVirt_3.3 > > > > Martin Perina > > > ----- Original Message ----- >> From: "Michal Skrivanek" <michal.skrivanek(a)redhat.com&gt; >> To: engine-devel(a)ovirt.org >> Sent: Wednesday, July 3, 2013 12:03:13 PM >> Subject: Re: [Engine-devel] SSH Soft Fencing >> >> >> On Jul 2, 2013, at 10:44 , Eli Mesika <emesika(a)redhat.com&gt; wrote: >> >>> >>> >>> ----- Original Message ----- >>>> 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. >> >> 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:-) >> > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >