[ClusterLabs] Pacemaker in puppet with cib.xml?
Stephano-Shachter, Dylan
dstathis at seas.harvard.edu
Thu Jul 21 20:24:22 UTC 2016
Thanks for all of the help!
On Thu, Jul 21, 2016 at 4:16 PM, Jan Pokorný <jpokorny at redhat.com> wrote:
> On 21/07/16 16:02 -0400, Stephano-Shachter, Dylan wrote:
> > So I should be using "pcs cluster cib > file" to get the config and then
> > "pcs cluster cib-push --config file" to push it?
>
> If you are going to change the file using "pcs -f <file>" in the
> interim, definitely.
>
> It's perhaps more intuitive to use "pcs cluster cib <file>" form,
> but whatever you like.
>
> > Also I shouldn't have to add --config to the pcs -f commands right?
>
> True, --config only applies to those cib/cib-push commands
> (and should be avoided/used, respectively as explained).
>
> > On Thu, Jul 21, 2016 at 3:51 PM, Jan Pokorný <jpokorny at redhat.com>
> wrote:
> >
> >> On 21/07/16 13:52 -0500, Ken Gaillot wrote:
> >>> On 07/21/2016 01:35 PM, Stephano-Shachter, Dylan wrote:
> >>>> I want to put the pacemaker config for my two node cluster in puppet
> >>>> but, since it is just one cluster, it seems overkill to use the
> corosync
> >>>> module. If I just have puppet push cib.xml to each machine, will that
> >>>> work? To make changes, I would just use pcs to update things and then
> >>>> copy cib.xml back to puppet. I am not sure what happens when you
> change
> >>>> cib.xml while the cluster is running. Is it safe?
> >>>
> >>> No, pacemaker checksums the CIB and won't accept a file that isn't
> >>> properly signed. Also, the cluster automatically synchronizes changes
> >>> made to the CIB across all nodes, so there is no need to push changes
> >>> more than once.
> >>>
> >>> Since you're using pcs, the update process could go like this:
> >>>
> >>> # Get the current configuration:
> >>> pcs cluster cib --config > cib-new.xml
> >>
> >> As I feel guilty for contributing to this misconception with clufter
> >> "pcs commands" output at one point (also see
> >> https://bugzilla.redhat.com/1328078; still part of the blame
> >> is in pcs I believe: https://bugzilla.redhat.com/1328066),
> >> something has just started screaming in me:
> >>
> >> DO NOT USE pcs cluster cib WITH --config LIKE SUGGESTED, BUT RATHER:
> >>
> >> pcs cluster cib > cib-new.xml
> >>
> >>> # Make changes:
> >>> pcs -f cib-new.xml <whatever-command-you-want>
> >>> <etc.>
> >>
> >> ...as otherwise the modifications like this ^ would fail.
> >>
> >>> # Upload the configuration changes to the cluster:
> >>> pcs cluster cib-push --config cib-new.xml
> >>
> >> Note that with cib-push, --config is OK, moreover it's vital as you
> >> really don't want to propagate stale status section and what not
> >> when changing modifying configuration.
> >>
> >> Yes, it's counterintuitive to have this asymmetry and it could be
> >> made to work with some added effort at the side of pcs with
> >> the original, disapproved, sequence as-is, but that's perhaps
> >> sound of the future per the referenced pcs bug.
> >> So take this idiom as a rule of thumb not to be questioned
> >> any time soon.
> >>
> >>> Using "--config" is important so you only work with the configuration
> >>> section of the CIB, and not the dynamically determined cluster
> >>> properties and status.
> >>
> >> (This, apparently, justifies just the cib-push use.)
> >>
> >>>
> >>> The first and last commands can be done on any one node, with the
> >>> cluster running. The "pcs -f" commands can be done anywhere/anytime.
>
> --
> Jan (Poki)
>
> _______________________________________________
> 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/20160721/e8308636/attachment.htm>
More information about the Users
mailing list