[Engine-devel] SSH Soft Fencing
Yair Zaslavsky
yzaslavs at redhat.com
Wed Jul 3 14:44:54 UTC 2013
----- Original Message -----
> From: "Barak Azulay" <bazulay at redhat.com>
> To: "Martin Perina" <mperina at redhat.com>, "Yaniv Bronheim" <ybronhei at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, July 3, 2013 5:24:21 PM
> Subject: Re: [Engine-devel] SSH Soft Fencing
>
>
>
> ----- 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
My 2 cents -
Actually, Since Martin's work is merged, and Yaniv already has in one of his patches fixes to all relevant places in code
he will probably need to add a fix around ssh soft fencing area (or at least coordinate this with Martin).
Both Yaniv and Martin are already aware of this.
Yair
>
> >
> >
> > >
> > > 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
> >
> >
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
More information about the Devel
mailing list