[Pacemaker] Proposed new stonith topology syntax

Digimer linux at alteeve.com
Fri Feb 3 13:58:25 EST 2012

On 02/03/2012 01:50 PM, Vladislav Bogdanov wrote:
> [snip]
> Why not to implement subsequent 'ons' after all 'offs' are confirmed?
> With some configurable delay f.e.
> That would be great for careful admins who keep fencing device lists actual.
>>From admin's PoV, reset and reset-like on-off operations should not
> differ in a result, offending host should be restarted if admin says
> 'restart' or 'reboot' in fencing parameters for that host (sorry, do not
> remember which one is used).
> Need in manual 'on' looks like a limitation for me so I wouldn't use
> such fencing mechanism. I prefer to have everything automated and
> predictable as much as possible.
> If 'on' is not done, then fencing is not doing what you've specified
> (for 'reboot/reset' action).
> Even more, if we need to do 'reset' of a host which has two PSUs
> connected to two different PDUs, then it should be translated to
> 'all-off' - 'delay' - 'all-on' automatically. I would like such powerful
> fencing system very much (yes, I'm a careful admin).
> I understand that implementation will require some efforts (even for so
> great programmer like you Andrew), but that would be a really useful
> feature,
> Best,
> Vladislav

in rhcs, this is how "reset" works. First it 'off's all devices in the
larger method and then checks all to make sure they are, in fact, off.
At this point, the fence action is deemed to have succeeded and a
cursory "on" is sent to the same devices. Whether they actually come
back on or not is of no concern to the fence action.

E-Mail:              digimer at alteeve.com
Papers and Projects: https://alteeve.com

More information about the Pacemaker mailing list