[Engine-devel] SSH Soft Fencing

Livnat Peer lpeer at redhat.com
Mon Jul 1 09:57:34 UTC 2013


On 07/01/2013 11:27 AM, Yair Zaslavsky wrote:
> 
> 
> ----- Original Message -----
>> From: "Martin Perina" <mperina at redhat.com>
>> To: engine-devel at 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.

>>
>>
>> Martin
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 




More information about the Devel mailing list