29.06.2013 02:22, Andrew Beekhof wrote: > > On 29/06/2013, at 12:22 AM, Digimer <li...@alteeve.ca> wrote: > >> On 06/28/2013 06:21 AM, Andrew Beekhof wrote: >>> >>> On 28/06/2013, at 5:22 PM, Lars Marowsky-Bree <l...@suse.com> wrote: >>> >>>> On 2013-06-27T12:53:01, Digimer <li...@alteeve.ca> wrote: >>>> >>>>> primitive fence_n01_psu1_off stonith:fence_apc_snmp \ >>>>> params ipaddr="an-p01" pcmk_reboot_action="off" port="1" >>>>> pcmk_host_list="an-c03n01.alteeve.ca" >>>>> primitive fence_n01_psu1_on stonith:fence_apc_snmp \ >>>>> params ipaddr="an-p01" pcmk_reboot_action="on" port="1" >>>>> pcmk_host_list="an-c03n01.alteeve.ca" >>>> >>>> So every device twice, including location constraints? I see potential >>>> for optimization by improving how the fence code handles this ... That's >>>> abhorrently complex. (And I'm not sure the 'action' parameter ought to >>>> be overwritten.) >>> >>> I'm not crazy about it either because it means the device is tied to a >>> specific command. >>> But it seems to be something all the RHCS people try to do... >> >> Maybe something in the rhcs water cooler made us all mad... ;) >> >>>> Glad you got it working, though. >>>> >>>>> location loc_fence_n01_ipmi fence_n01_ipmi -inf: an-c03n01.alteeve.ca >>>> [...] >>>> >>>> I'm not sure you need any of these location constraints, by the way. Did >>>> you test if it works without them? >>>> >>>>> Again, this is after just one test. I will want to test it several more >>>>> times before I consider it reliable. Ideally, I would love to hear >>>>> Andrew or others confirm this looks sane/correct. >>>> >>>> It looks correct, but not quite sane. ;-) That seems not to be >>>> something you can address, though. I'm thinking that fencing topology >>>> should be smart enough to, if multiple fencing devices are specified, to >>>> know how to expand them to "first all off (if off fails anywhere, it's a >>>> failure), then all on (if on fails, it is not a failure)". That'd >>>> greatly simplify the syntax. >>> >>> The RH agents have apparently already been updated to support multiple >>> ports. >>> I'm really not keen on having the stonith-ng doing this. >> >> This doesn't help people who have dual power rails/PDUs for power >> redundancy. > > I'm yet to be convinced that having two PDUs is helping those people in the > first place. > If it were actually useful, I suspect more than two/three people would have > asked for it in the last decade.
I'm just silently waiting for this to happen. Although I use different fencing scheme (and plan to use even more different one), that is very nice fall-back path for me. And I strongly prefer all complexities like reboot -> off-off-on-on to be hidden from the configuration. Naturally, that is task for the entity which has whole picture of what to do - stonithd. Just my 'IMHO'. And, to PSU/PDU. I, like Digimer, always separate power circuits as much as possible. Of course I always use redundant PSUs. 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
