[Engine-devel] SSH Soft Fencing

[Barak Azulay]

----- Original Message -----
> From: "Martin Perina" <mperina at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Wednesday, July 3, 2013 3:39:20 PM
> Subject: Re: [Engine-devel] SSH Soft Fencing
> 
> 
> 
> ----- Original Message -----
> > From: "Livnat Peer" <lpeer at redhat.com>
> > To: "Martin Perina" <mperina at redhat.com>
> > Cc: engine-devel at 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
> > 
> 
> Well, SSH connection uses engine default SSH key, no password. So I think
> this is usable for all hosts.

correct, SSH public key is deployed as a part of bootstrap & host-deploy from day one.
So no need to save the password anywhere.

Marin - Where do you take the username (currently only root is supported), but we intend to move away from it,
Actually Yaniv.B as added it to the DB as first stage - just making sure you'll use that.

Thanks
Barak

> 
> 
> > 
> > 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 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:-)
> > >>
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
>