On 06/27/2013 05:43 PM, Yair Zaslavsky wrote:
----- Original Message -----
From: "Eli Mesika" <emesika@redhat.com> To: "Martin Perina" <mperina@redhat.com> Cc: engine-devel@ovirt.org, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Barak Azulay" <bazulay@redhat.com> Sent: Thursday, June 27, 2013 3:48:39 PM Subject: Re: SSH Soft Fencing
----- Original Message -----
From: "Martin Perina" <mperina@redhat.com> To: engine-devel@ovirt.org Cc: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Barak Azulay" <bazulay@redhat.com>, "Eli Mesika" <emesika@redhat.com> Sent: Thursday, June 27, 2013 1:51:06 PM Subject: SSH Soft Fencing
Hi,
SSH Soft Fencing is a new feature for 3.3 and it tries to restart VDSM using SSH connection on non responsive hosts prior to real fencing. More info can be found at
http://www.ovirt.org/Automatic_Fencing#Automatic_Fencing_in_oVirt_3.3
In current SSH Soft Fencing implementation the restart VDSM using SSH command is part of standard fencing implementation in VdsNotRespondingTreatmentCommand. But this command is executed only if a host has a valid PM configuration. If host doesn't have a valid PM configuration, the execution of the command is disabled and host state is change to Non Responsive.
So my question are:
1) Should SSH Soft Fencing be executed on hosts without valid PM configuration?
I think that the answer should be yes. The vdsm restart will solve most of problems , so why not using it whether a PM agent is defined or not. I agree. I would like to say that I also don't like the fact that VdsNotRespondingTreatment extends RestartVdsCommand. One should ask if "non responding treatment is a restart vds operation" or maybe RestartVdsCommand is just a step in the non responding treatment (inheritance vs containment/delegation). I think that VdsNotRespodingTreatment should delegate the call to RestartVdsCommand as the 2nd step after issuing the Soft Fencing command. Thoughts anyone?
I agree. The purpose of this feature is to add escalation step when handling non responsive host. Power fencing is only a step in the escalation flow. so should be called from within the main flow controller (the VdsNotRespodingTreatment). Maybe we'd like this to be fine tuned by a custom policy in future versions.
2) Should VDSM restart using SSH command be reimplemented as standalone command to be usable also in other parts of engine? If 1) is true, I think it will have to be done anyway.
I agree here.
+1
+1 The VDSM restart is a step in the escalation flow, and it should not be tightly coupled with the non-responsive treatment implementation.
Martin Perina
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel