Re: [ClusterLabs] Pacemaker in puppet with cib.xml?
Thanks for all of the help! On Thu, Jul 21, 2016 at 4:16 PM, Jan Pokorný <jpoko...@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 " in the > interim, definitely. > > It's perhaps more intuitive to use "pcs cluster cib " 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 > >>> > >> > >> ...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@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@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
Re: [ClusterLabs] Pacemaker in puppet with cib.xml?
So I should be using "pcs cluster cib > file" to get the config and then "pcs cluster cib-push --config file" to push it? Also I shouldn't have to add --config to the pcs -f commands right? 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 > > > > ...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@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@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
Re: [ClusterLabs] Pacemaker in puppet with cib.xml?
I am familiar with pcs cluster cib. What I am thinking of doing is running "pcs cluster cib --config > config.xml" to get a valid config. I will then put config.xml on the puppet server and have it push the file and run "pcs cluster cib-push --config config.xml" every hour. Will this cause any problems due to pushing the config multiple times? This would allow me to make small edits to the file in puppet and have it pushed automatically. If I wanted to make any big changes, I can make them with pcs and just pull another config. On Thu, Jul 21, 2016 at 2:52 PM, Ken Gaillot <kgail...@redhat.com> wrote: > On 07/21/2016 01:35 PM, Stephano-Shachter, Dylan wrote: > > Hello all, > > > > 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 > > # Make changes: > pcs -f cib-new.xml > > > # Upload the configuration changes to the cluster: > pcs cluster cib-push --config cib-new.xml > > Using "--config" is important so you only work with the configuration > section of the CIB, and not the dynamically determined cluster > properties and status. > > 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. > > > ___ > 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 > ___ 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
[ClusterLabs] Pacemaker in puppet with cib.xml?
Hello all, 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? Thanks for any help, Dylan ___ 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
Re: [ClusterLabs] Can't get nfs4 to work.
I had the line, RPCNFSDARGS="-N 2 -N 4" which I changed to RPCNFSDARGS="-N 2" It turns out someone else who had initially set up the nfs server had disabled v4 explicitly. On Fri, Jun 3, 2016 at 10:25 AM, Kai Dupkewrote: > On 06/03/2016 04:17 PM, Dylan Stephano-Shachter wrote: > > Okay turns out the issue was not related to pacemaker (I thought it was). > > It was just in issue with the nfs config file. > > Which was? Even if it is trivial, it might help us to avoid such and > give the right hint the next time. > > regards, > Kai Dupke > Senior Product Manager > Server Product Line > -- > Sell not virtue to purchase wealth, nor liberty to purchase power. > Phone: +49-(0)5102-9310828 Mail: kdu...@suse.com > Mobile: +49-(0)173-5876766 WWW: www.suse.com > > SUSE Linux GmbH - Maxfeldstr. 5 - 90409 Nuernberg (Germany) > GF:Felix Imendörffer,Jane Smithard,Graham Norton,HRB 21284 (AG Nürnberg) > > ___ > 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 > ___ 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
Re: [ClusterLabs] Can't get nfs4 to work.
Okay turns out the issue was not related to pacemaker (I thought it was). It was just in issue with the nfs config file. On Thu, Jun 2, 2016 at 5:04 PM, Jan Pokorný <jpoko...@redhat.com> wrote: > On 02/06/16 02:35 +0200, Dennis Jacobfeuerborn wrote: > > On 01.06.2016 20:25, Stephano-Shachter, Dylan wrote: > >> I have just finished setting up my HA nfs cluster and I am having a > small > >> problem. I would like to have nfs4 working but whenever I try to mount I > >> get the following message, > >> > >> mount: no type was given - I'll assume nfs because of the colon > > > > I'm not sure if the type "nfs" is supposed to work with v4 as well but > > on my systems the mounts use the explicit type "nfs4" so you can try > > mounting with "-t nfs4". > > $ rpm -qf $(man -w mount.nfs) > > nfs-utils-1.3.3-7.rc4.fc22.x86_64 > > $ man mount.nfs | fmt -w70 | grep -A2 Under > > Under Linux 2.6.32 and later kernel versions, mount.nfs can > > mount all NFS file system versions. Under earlier Linux > > kernel versions, mount.nfs4 must be used for mounting NFSv4 > > file systems while mount.nfs must be used for NFSv3 and v2. > > -- > Jan (Poki) > > ___ > 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 > > ___ 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
[ClusterLabs] Can't get nfs4 to work.
Hello all, I have just finished setting up my HA nfs cluster and I am having a small problem. I would like to have nfs4 working but whenever I try to mount I get the following message, mount: no type was given - I'll assume nfs because of the colon mount.nfs: timeout set for Wed Jun 1 10:08:45 2016 mount.nfs: trying text-based options 'vers=4,addr=10.243.16.116,clientaddr=10.243.18.22' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'addr=10.243.16.116' mount.nfs: prog 13, trying vers=3, prot=6 mount.nfs: trying 10.243.16.116 prog 13 vers 3 prot TCP port 2049 mount.nfs: prog 15, trying vers=3, prot=17 mount.nfs: trying 10.243.16.116 prog 15 vers 3 prot UDP port 20048 I can not figure out why version 4 is not supported. My nfsserver resource and export resource are Resource: ch_nfs (class=ocf provider=heartbeat type=nfsserver) Attributes: nfs_shared_infodir=/data/nfs nfs_ip=10.243.16.116 Operations: start interval=0s timeout=40 (ch_nfs-start-interval-0s) stop interval=0s timeout=20s (ch_nfs-stop-interval-0s) monitor interval=0s (ch_nfs-monitor-interval-30s) Resource: ch_export_testdata_18 (class=ocf provider=heartbeat type=exportfs) Attributes: clientspec=10.243.18.0/255.255.255.0 options=rw,no_root_squash directory=/data/testdata fsid=1 Operations: start interval=0s timeout=40 (ch_export_testdata_18-start-interval-0s) stop interval=0s timeout=120 (ch_export_testdata_18-stop-interval-0s) monitor interval=10 timeout=20 (ch_export_testdata_18-monitor-interval-10) ___ 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