----- Original Message ----- > From: "Barak Azulay" <bazu...@redhat.com> > To: "Martin Perina" <mper...@redhat.com>, "Yaniv Bronheim" > <ybron...@redhat.com> > Cc: engine-devel@ovirt.org > Sent: Wednesday, July 3, 2013 5:24:21 PM > Subject: Re: [Engine-devel] SSH Soft Fencing > > > > ----- Original Message ----- > > From: "Martin Perina" <mper...@redhat.com> > > To: engine-devel@ovirt.org > > Sent: Wednesday, July 3, 2013 3:39:20 PM > > Subject: Re: [Engine-devel] SSH Soft Fencing > > > > > > > > ----- Original Message ----- > > > From: "Livnat Peer" <lp...@redhat.com> > > > To: "Martin Perina" <mper...@redhat.com> > > > Cc: engine-devel@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.skriva...@redhat.com> > > > >> To: engine-devel@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 <emes...@redhat.com> wrote: > > > >> > > > >>> > > > >>> > > > >>> ----- Original Message ----- > > > >>>> From: "Livnat Peer" <lp...@redhat.com> > > > >>>> To: "Yair Zaslavsky" <yzasl...@redhat.com> > > > >>>> Cc: engine-devel@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" <mper...@redhat.com> > > > >>>>>> To: engine-devel@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@ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
