Hi Andrew, Dejan, all, 25.01.2012 03:24, Andrew Beekhof wrote: [snip] >>> If they're for the same host but different devices, then at most >>> you'll get the commands sent in parallel, guaranteeing simultaneous is >>> near impossible. >> >> Yes, what I meant is almost simultaneous, i.e. that both ports >> are for a while turned "off" at the same time. I'm not sure how >> does it work in reality. For instance, how long does the reset >> command keep the power off on the outlet. So, it should be >> "simultanous enough" :) > > I dont think 'reboot' is an option if you're using multiple devices. > You have to use 'off' (followed by a manual 'on') for any kind of reliability. >
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 _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
