On 06/30/2013 07:35 PM, Barak Azulay wrote:
----- Original Message -----
From: "Barak Azulay" <bazulay@redhat.com> To: "Martin Perina" <mperina@redhat.com> Cc: "Yair Zaslavsky" <yzaslavs@redhat.com>, engine-devel@ovirt.org, "Eli Mesika" <emesika@redhat.com> Sent: Thursday, June 27, 2013 8:31:35 PM Subject: Re: SSH Soft Fencing
----- Original Message -----
From: "Eli Mesika" <emesika@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "Martin Perina" <mperina@redhat.com>, engine-devel@ovirt.org, "Barak Azulay" <bazulay@redhat.com> Sent: Thursday, June 27, 2013 5:55:29 PM Subject: Re: SSH Soft Fencing
----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "Martin Perina" <mperina@redhat.com>, engine-devel@ovirt.org, "Barak Azulay" <bazulay@redhat.com> Sent: Thursday, June 27, 2013 5:43:17 PM Subject: Re: SSH Soft Fencing
----- 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?
That would be a nice and needed re-factoring
I would say yes - but would add it only with appropriate configuration (enableAutoSoftVdsmRestartWhenNoPMAvailable .... I hate the name)
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
On one hand it makes sense, but I have several questions on the above: - Who do we think may want to use such a command ?
I believe you'll agree that right encapsulation and decoupling is part of writing a maintainable code, it is not necessarily about reusing it.
- Should (or even can) we limit the use of such command to noneResponsiveTreatment ?
At this point this command would be executed only within the noneResponsiveTreatment flow. We don't need to model this in the REST API nor in the UI, decoupling the vdsm fencing code is just an internal implementation detail.
Having general commands available to all code when there is only one specific case we are using it might be a bit riskey, Especially when we talk about restarting something.
I am not sure what is the risk?
Martin ? Eli? Yair?
Can you please refer to the issue above ?
Thoughts ?
Martin Perina
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel