[ClusterLabs] Pacemaker in puppet with cib.xml?

[Jan Pokorný]

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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20160721/03b101e4/attachment-0004.sig>