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ý <jpoko...@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)
pgpiLRX9bi11r.pgp
Description: PGP signature
_______________________________________________ Users mailing list: Users@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