[Engine-devel] SSH Soft Fencing

[Martin Perina]

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 at redhat.com>
> To: engine-devel at 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 at redhat.com> wrote:
> 
> > 
> > 
> > ----- Original Message -----
> >> From: "Livnat Peer" <lpeer at redhat.com>
> >> To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> >> Cc: engine-devel at 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 at redhat.com>
> >>>> To: engine-devel at 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:-)
>