[Engine-devel] SSH Soft Fencing

[Livnat Peer]

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


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 at redhat.com>
>> To: engine-devel at 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 at redhat.com> wrote:
>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Livnat Peer" <lpeer at redhat.com>
>>>> To: "Yair Zaslavsky" <yzaslavs at redhat.com>
>>>> Cc: engine-devel at 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 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.
>>
>> 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 at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>