----- 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 > > > > > > 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
