<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>From: andrew@beekhof.net<br><div>Date: Fri, 4 Jul 2014 22:50:28 +1000<br>To: pacemaker@oss.clusterlabs.org<br>Subject: Re: [Pacemaker] Pacemaker 1.1: cloned stonith resources require --force to be added to levels<br><br><pre> <br>On 4 Jul 2014, at 1:29 pm, Giuseppe Ragusa <giuseppe.ragusa@hotmail.com> wrote:<br> <br>> >> Hi all,<br>> >> while creating a cloned stonith resource<br>> > <br>> > Any particular reason you feel the need to clone it?<br>> <br>> In the end, I suppose it's only a "purist mindset" :) because it is a PDU whose power outlets control both nodes, so<br>> its resource "should be" active (and monitored) on both nodes "independently".<br>> I understand that it would work anyway, leaving it not cloned and not location-constrained<br>> just as regular, "dedicated" stonith devices would not need to be location-constrained, right?<br>> <br>> >> for multi-level STONITH on a fully-up-to-date CentOS 6.5 (pacemaker-1.1.10-14.el6_5.3.x86_64):<br>> >> <br>> >> pcs cluster cib stonith_cfg<br>> >> pcs -f stonith_cfg stonith create pdu1 fence_apc action="off" \<br>> >> ipaddr="pdu1.verolengo.privatelan" login="cluster" passwd="test" \ pcmk_host_map="cluster1.verolengo.privatelan:3,cluster1.verolengo.privatelan:4,cluster2.verolengo.privatelan:6,cluster2.verolengo.privatelan:7" \<br>> >> pcmk_host_check="static-list" pcmk_host_list="cluster1.verolengo.privatelan,cluster2.verolengo.privatelan" op monitor interval="240s"<br>> >> pcs -f stonith_cfg resource clone pdu1 pdu1Clone<br>> >> pcs -f stonith_cfg stonith level add 2 cluster1.verolengo.privatelan pdu1Clone<br>> >> pcs -f stonith_cfg stonith level add 2 cluster2.verolengo.privatelan pdu1Clone<br>> >> <br>> >> <br>> >> the last 2 lines do not succeed unless I add the option "--force" and even so I still get errors when issuing verify:<br>> >> <br>> >> [root@cluster1 ~]# pcs stonith level verify<br>> >> Error: pdu1Clone is not a stonith id<br>> > <br>> > If you check, I think you'll find there is no such resource as 'pdu1Clone'.<br>> > I don't believe pcs lets you decide what the clone name is.<br>> <br>> You're right! (obviously ;> )<br>> It's been automatically named pdu1-clone<br>> <br>> I suppose that there's still too much crmsh in my memory :)<br>> <br>> Anyway, removing the stonith level (to start from scratch) and using the correct clone name does not change the result:<br>> <br>> [root@cluster1 etc]# pcs -f stonith_cfg stonith level add 2 cluster1.verolengo.privatelan pdu1-clone<br>> Error: pdu1-clone is not a stonith id (use --force to override)<br> <br>I bet we didn't think of that.<br>What if you just do:<br> <br> pcs -f stonith_cfg stonith level add 2 cluster1.verolengo.privatelan pdu1<br> <br>Does that work?<br> <br>------------------------------------------------------------------------<br><br>Yes, no errors at all and verify successful.<br><br>Remember that a full real test (to verify actual second level functionality in presence of first level failure)<br>is still pending for both the plain and cloned setup.<br><br>Apropos: I read through the list archives that stonith resources (being resources, after all)<br>could themselves cause fencing (!) if failing (start, monitor, stop) and that an ad-hoc<br>on-fail setting could be used to prevent that.<br>Maybe my aforementioned naive testing procedure (pull the iLO cable) could provoke that?<br>Would you suggest to configure such an on-fail option?<br><br>Many thanks again for your help (and all your valuable work, of course!).<br><br>Regards,<br>Giuseppe<br></pre></div> </div></body>
</html>