<div dir="ltr"><div>>> <span style="font-size:12.8000001907349px">You can, but I’m failing to understand why you want to wipe the config clean each time in the first place.</span></div><div><br></div>So far, in our solution we provide users with a few options so far.<div>They are:</div><div> - automatic fail-back on/off</div><div> - a set of three additional resources to run (on/off) (depends on user's need)</div><div><br></div><div>We decided to wipe out previous configuration when the cluster starts, so there is no need of tracking configuration changes in the cluster.</div><div><br></div><div>BTW, is it sufficient to create only "cib.xml", or "cib.xml.sig" and "cib.last" are also must be created?</div><div><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Thank you,<div>Kostya</div></div></div></div>
<br><div class="gmail_quote">On Tue, Aug 4, 2015 at 3:53 AM, Andrew Beekhof <span dir="ltr"><<a href="mailto:andrew@beekhof.net" target="_blank">andrew@beekhof.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 4 Aug 2015, at 1:48 am, Kostiantyn Ponomarenko <<a href="mailto:konstantin.ponomarenko@gmail.com">konstantin.ponomarenko@gmail.com</a>> wrote:<br>
><br>
> Hi folks,<br>
><br>
> Is it possible to have a configured initial cib.xml file?<br>
<br>
</span>yes, but if other members of the cluster are active it might be effectively ignored<br>
<span class=""><br>
><br>
> In my solution there is a script that applies configuration automatically each boot.<br>
> But before that, another script (before starting pacemaker) does:<br>
> # rm -rf /var/lib/pacemaker/cib/*<br>
> in order to clean up the previous config.<br>
> The clean up is made each time despite anything.<br>
> Then, if the node has a DC status it runs a shell script with crm commands to set up cluster.<br>
<br>
</span>So you start with an empty cib and then script the addition of resources once the node becomes a DC?<br>
Thats… odd.<br>
<span class=""><br>
><br>
> The thing is - every group boot, when all nodes are rebooted, I have those noisy messages in the log, which say that no STONITH was configured:<br>
><br>
> 2015 Aug 3 17:56:59 +03:00 daemon.err<27> pengine[37739]: error: unpack_resources: Resource start-up disabled since no STONITH resources have been defined<br>
> 2015 Aug 3 17:56:59 +03:00 daemon.err<27> pengine[37739]: error: unpack_resources: Either configure some or disable STONITH with the stonith-enabled option<br>
> 2015 Aug 3 17:56:59 +03:00 daemon.err<27> pengine[37739]: error: unpack_resources: NOTE: Clusters with shared data need STONITH to ensure data integrity<br>
> 2015 Aug 3 17:56:59 +03:00 daemon.err<27> pengine[37739]: error: unpack_resources: Resource start-up disabled since no STONITH resources have been defined<br>
> 2015 Aug 3 17:56:59 +03:00 daemon.err<27> pengine[37739]: error: unpack_resources: Either configure some or disable STONITH with the stonith-enabled option<br>
> 2015 Aug 3 17:56:59 +03:00 daemon.err<27> pengine[37739]: error: unpack_resources: NOTE: Clusters with shared data need STONITH to ensure data integrity<br>
><br>
> The configuration scrip set-up STONITH devices, but the messages still appear, because the configuration was recreated by Pacemaker and doesn't have STONITH yet.<br>
<br>
</span>We can’t predict the future I’m afraid. Pacemaker can only work with the configuration is currently has.<br>
<span class=""><br>
> So, the idea is to get read of this kind of error messages.<br>
><br>
> As a possible option I am thinking of creating an initial cib.xml file with configured STONITH in it, and put it in the place after cleaning up previous config.<br>
> So just wanted to check my idea with somebody, so I am sure it won't lead to any troubles in future ;-)<br>
<br>
</span>You can, but I’m failing to understand why you want to wipe the config clean each time in the first place.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Thank you,<br>
> Kostya<br>
> _______________________________________________<br>
> Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
> <a href="http://clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://clusterlabs.org/mailman/listinfo/users</a><br>
><br>
> Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
> Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
> Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
<br>
<br>
_______________________________________________<br>
Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
<a href="http://clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://clusterlabs.org/mailman/listinfo/users</a><br>
<br>
Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
</div></div></blockquote></div><br></div>