06.02.2012 01:55, Andrew Beekhof wrote: > On Sat, Feb 4, 2012 at 5:50 AM, Vladislav Bogdanov <bub...@hoster-ok.com> > wrote: >> 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? > > That could be possible in the future. > However since none of this was possible in the old stonithd, its not > something I plan for the initial implementation. > > Also, you're requiring an extra level of intelligence in stonith-ng, > to know that even though the admin asked for 'reboot' and the devices > support 'reboot', that we should ignore that and do 'off' + 'on' in > some specific scenarios. > >> 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. > > Then don't put a node under the control of two devices. > Have it be two ports on the same host and you wont hit this limitation.
It's a SPOF in the case of PDUs. I do not use PDUs at all, I have everything ready to shorten 'reset' lines on servers instead of plugging off power cords, just waiting for linear fencing topology to be implemented in both snonith-ng and crmsh. So, I just care about generic admin who wants to use PDUs for fencing. > >> 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 > > _______________________________________________ > 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 _______________________________________________ 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
