5:44 p.m.
----- Original Message -----
From: "Barak Azulay" <bazulay(a)redhat.com>
To: "Martin Perina" <mperina(a)redhat.com>, "Yaniv Bronheim"
<ybronhei(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Wednesday, July 3, 2013 5:24:21 PM
Subject: Re: [Engine-devel] SSH Soft Fencing
----- Original Message -----
> From: "Martin Perina" <mperina(a)redhat.com>
> To: engine-devel(a)ovirt.org
> Sent: Wednesday, July 3, 2013 3:39:20 PM
> Subject: Re: [Engine-devel] SSH Soft Fencing
>
>
>
> ----- Original Message -----
> > From: "Livnat Peer" <lpeer(a)redhat.com>
> > To: "Martin Perina" <mperina(a)redhat.com>
> > 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
> >
>
> 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(a)redhat.com>
> > >> 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>
wrote:
> > >>
> > >>>
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Livnat Peer" <lpeer(a)redhat.com>
> > >>>> To: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
> > >>>> 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>
> > >>>>>> 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
> > >
> >
> >
> _______________________________________________
> 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