[ClusterLabs] Configuration of Initial cib.xml

[Kostiantyn Ponomarenko]

>> You can, but I’m failing to understand why you want to wipe the config
clean each time in the first place.

So far, in our solution we provide users with a few options so far.
They are:
    - automatic fail-back on/off
    - a set of three additional resources to run (on/off) (depends on
user's need)

We decided to wipe out previous configuration when the cluster starts, so
there is no need of tracking configuration changes in the cluster.

BTW, is it sufficient to create only "cib.xml", or "cib.xml.sig" and
"cib.last" are also must be created?



Thank you,
Kostya

On Tue, Aug 4, 2015 at 3:53 AM, Andrew Beekhof <andrew at beekhof.net> wrote:

>
> > On 4 Aug 2015, at 1:48 am, Kostiantyn Ponomarenko <
> konstantin.ponomarenko at gmail.com> wrote:
> >
> > Hi folks,
> >
> > Is it possible to have a configured initial cib.xml file?
>
> yes, but if other members of the cluster are active it might be
> effectively ignored
>
> >
> > In my solution there is a script that applies configuration
> automatically each boot.
> > But before that, another script (before starting pacemaker) does:
> >     # rm -rf /var/lib/pacemaker/cib/*
> > in order to clean up the previous config.
> > The clean up is made each time despite anything.
> > Then, if the node has a DC status it runs a shell script with crm
> commands to set up cluster.
>
> So you start with an empty cib and then script the addition of resources
> once the node becomes a DC?
> Thats… odd.
>
> >
> > 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:
> >
> > 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
> > 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
> > 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
> > 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
> > 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
> > 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
> >
> > 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.
>
> We can’t predict the future I’m afraid.  Pacemaker can only work with the
> configuration is currently has.
>
> > So, the idea is to get read of this kind of error messages.
> >
> > 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.
> > So just wanted to check my idea with somebody, so I am sure it won't
> lead to any troubles in future ;-)
>
> You can, but I’m failing to understand why you want to wipe the config
> clean each time in the first place.
>
> >
> > Thank you,
> > Kostya
> > _______________________________________________
> > Users mailing list: Users at clusterlabs.org
> > http://clusterlabs.org/mailman/listinfo/users
> >
> > Project Home: http://www.clusterlabs.org
> > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> > Bugs: http://bugs.clusterlabs.org
>
>
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/users
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20150804/9b14085a/attachment.htm>