----- Original Message -----
From: "Barak Azulay" <bazulay@redhat.com> To: "Martin Perina" <mperina@redhat.com>, "Yaniv Bronheim" <ybronhei@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" <mperina@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" <lpeer@redhat.com> To: "Martin Perina" <mperina@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.skrivanek@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 <emesika@redhat.com> wrote:
----- Original Message ----- > From: "Livnat Peer" <lpeer@redhat.com> > To: "Yair Zaslavsky" <yzaslavs@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" <mperina@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