Re: [ClusterLabs] Pacemaker in puppet with cib.xml?

2016-07-21 Thread Stephano-Shachter, Dylan
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?

2016-07-21 Thread Stephano-Shachter, Dylan
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?

2016-07-21 Thread Stephano-Shachter, Dylan
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?

2016-07-21 Thread Stephano-Shachter, Dylan
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.

2016-06-03 Thread Stephano-Shachter, Dylan
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 Dupke  wrote:

> 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.

2016-06-03 Thread Stephano-Shachter, Dylan
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.

2016-06-01 Thread Stephano-Shachter, Dylan
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