Re: [ClusterLabs] Problem with pacemaker init.d script

[Jan Pokorný]

On 12/07/18 18:54 +0200, Jan Pokorný wrote:
>>> On 12 Jul 2018, at 15:47, Jan Pokorný  wrote:
>>> On 11/07/18 18:43 +0200, Salvatore D'angelo wrote:
>>> On Wed, 2018-07-11 at 18:43 +0200, Salvatore D'angelo wrote:
 [...] question is pacemaker install
 /etc/init.d/pacemaker script but its header is not compatible
 with newer system that uses LSB.
>>> 
>>> Combining LSB and "newer system" in one sentence is sort of ridiculous
>>> since LSB dates back to 2002 (LSB 1.1 seems to be first to actually
>>> explain headers like Default-Start [1]), and the concept of system
>>> initialization in the Linux context was gradually refined with
>>> projects like upstart and systemd.  
> 
> Sorry, forgot:

(sending faster than rechecking)

[1] https://refspecs.linuxfoundation.org/LSB_1.1.0/gLSB/initscrcomconv.html

-- 
Nazdar,
Jan (Poki)


pgprpiXZzoGqz.pgp
Description: PGP signature
___
Users mailing list: Users@clusterlabs.org
https://lists.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] Problem with pacemaker init.d script

[Jan Pokorný]

On 12/07/18 16:51 +0200, Salvatore D'angelo wrote:
> My “talent” as you said comes from a bad knowledge of system vs upstart vs 
> sysV mechanism.

Rule of thumb: aim at what's a first class citizen in your
distribution/system of choice -- for your particular situation,
others already indicated the choice is obvious.

Once you know which init system to target, you can become proficient
pretty fast with the basics (immediate start/stop, on-boot enablement
or otherwise).

> Let me only underline that I compile directly on target system and
> not a different machine.

That simplifies the surface, which is always better for
troubleshooting.

> Moreover, all ./configure requirements are met because when this
> didn’t happen the ./configure stopped (at least this is what I
> expected).

Rather a false assumption: some "features" are merely optional, meaning
the relevant functionality and/or files will simply be skipped, without
any fatal stop/big noise.  That's intentional and desired, one size
doesn't fit all.

> However, I’ll pay more attention the next time I’ll run ./configure
> to the output.

Great.

> For the moment, I have the workaround mentioned in the previous
> email because I only developed a proof of concepts.
> When we will start to create production code I’ll try to better
> understand how systemd works and how to use it to fix my issue.

Note that systemd per se is not causing any interferences, it's just
a mix of shortcomings (starting with a likely lack of some files in
your installation and ending with pettiness of LSB compatibility
software) that is to be blamed.  Luckily, it's solvable.

On the contrary, with systemd in the picture, you'll get some small
benefits incl. a possibility to run services through their native
systemd unit files (a tuned collection of directives determining how
to optimally run particular daemons) when provided, amongst others.
> 
>> On 12 Jul 2018, at 15:47, Jan Pokorný  wrote:
>> On 11/07/18 18:43 +0200, Salvatore D'angelo wrote:
>> On Wed, 2018-07-11 at 18:43 +0200, Salvatore D'angelo wrote:
>>> [...] question is pacemaker install
>>> /etc/init.d/pacemaker script but its header is not compatible
>>> with newer system that uses LSB.
>> 
>> Combining LSB and "newer system" in one sentence is sort of ridiculous
>> since LSB dates back to 2002 (LSB 1.1 seems to be first to actually
>> explain headers like Default-Start [1]), and the concept of system
>> initialization in the Linux context was gradually refined with
>> projects like upstart and systemd.  

Sorry, forgot:

[1] 

-- 
Nazdar,
Jan (Poki)


pgphpxBhdizDM.pgp
Description: PGP signature
___
Users mailing list: Users@clusterlabs.org
https://lists.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] Problem with pacemaker init.d script

[Salvatore D'angelo]

Hi Jan,

My “talent” as you said comes from a bad knowledge of system vs upstart vs sysV 
mechanism.
Let me only underline that I compile directly on target system and not a 
different machine.
Moreover, all ./configure requirements are met because when this didn’t happen 
the ./configure stopped (at least this is what I expected).
However, I’ll pay more attention the next time I’ll run ./configure to the 
output.

For the moment, I have the workaround mentioned in the previous email because I 
only developed a proof of concepts.
When we will start to create production code I’ll try to better understand how 
systemd works and how to use it to fix my issue.
Thank you for support.

> On 12 Jul 2018, at 15:47, Jan Pokorný  wrote:
> 
> Hello Salvatore,
> 
> we can cope with that without much trouble, but you seem to have
> a talent to present multiple related issues at once, or perhaps
> to start solving the problems from the too distant point :-) 
> 
> As mentioned, that's also fine, but let's separate them...
> 
> On 11/07/18 18:43 +0200, Salvatore D'angelo wrote:
> On Wed, 2018-07-11 at 18:43 +0200, Salvatore D'angelo wrote:
>> [...] question is pacemaker install
>> /etc/init.d/pacemaker script but its header is not compatible
>> with newer system that uses LSB.
> 
> Combining LSB and "newer system" in one sentence is sort of ridiculous
> since LSB dates back to 2002 (LSB 1.1 seems to be first to actually
> explain headers like Default-Start [1]), and the concept of system
> initialization in the Linux context was gradually refined with
> projects like upstart and systemd.  
> 
> What may have changed between older and newer Ubuntu, though,
> towards less compatibility (or contrary, more strictness on the
> headers/initscript meta-data) is that the compatibility support
> scripts/translators are written from scratch, leaving relaxed
> approach (the standard is also not that strict) behind ... or not,
> and this is just a new regression subsequently fixed later on:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588868
> 
> which matches your:
> 
>>> 11.07.2018 21:01, Salvatore D'angelo пишет:
 [...] system find that sysV is installed and try to leverage on
 update-rc.d scripts and the failure occurs:
 
 root@pg1:~# systemctl enable corosync
 corosync.service is not a native service, redirecting to 
 systemd-sysv-install
 Executing /lib/systemd/systemd-sysv-install enable corosync
 update-rc.d: error: corosync Default-Start contains no runlevels, aborting.
> 
> So I'd be inclined to think the existing initscripts can be used just
> fine in bug-free LSB initialization scenarios.  It'd be hence just
> your choice whether to apply the workaround for sysv-rc bug (?) that
> you've presented.
> 
> Anyway, as mentioned:
> 
>> On 11 Jul 2018, at 18:40, Andrei Borzenkov 
>> wrote:
>>> 16.04 is using systemd, you need to create systemd unit. I do
>>> not know if there is any compatibility layer to interpret
>>> upstart configuration like the one for sysvinit.
> 
> and
> 
>> On 11 Jul 2018, at 21:07, Andrei Borzenkov  wrote:
>>> Then you built corosync without systemd integration. systemd will prefer
>>> native units.
> 
> You shouldn't be using, not even indirectly, initscripts with
> systemd-enabled deployments, otherwise you ask for various dependency
> mismatches and other complications.
> 
> Which gets us to another problem in pacemaker context:
> 
> On Wed, 2018-07-11 at 18:43 +0200, Salvatore D'angelo wrote:
>> when I run “make install” anything is created for systemd env.
> 
> (presuming anything ~ nothing), because as Ken mentioned:
> 
> On 11 Jul 2018, at 19:29, Ken Gaillot  wrote:
> With Ubuntu 16, you should use "systemctl enable pacemaker" instead
> of update-rc.d.
> 
> So, if you haven't tried to build pacemaker on a system differing to
> the target one in some build-time important aspects, then I can guess
> you just hadn't ensured you have all systemd-related requisities
> installed at the time you've run "./configure".  Currently, it boils
> down to libdbus-1 library + development files (looks covered with
> "libdbus-1-dev" package) & working "systemctl" command from systemd
> suite.
> 
> Frankly, when people go the path of custom compilations, it's assumed
> they will get familiar with the build system tools, or at the very
> least will try to make a reason from what's written to the terminal
> -- Salvatore, if you were careful enough, you could observe lines
> like these if you had all such prerequisites right (alternatively,
> review config.log file):
> 
>> checking for DBUS... yes
>> checking for DBusBasicValue... yes
>> checking for systemd version query result via dbus-send... string "238"
>> checking whether to enable support for managing resources via systemd... yes
>> checking for systemd path for system unit files...  /usr/lib/systemd/system
> 
> If there was "no" or "borked" indications with some 

Re: [ClusterLabs] Problem with pacemaker init.d script

[Jan Pokorný]

Hello Salvatore,

we can cope with that without much trouble, but you seem to have
a talent to present multiple related issues at once, or perhaps
to start solving the problems from the too distant point :-) 

As mentioned, that's also fine, but let's separate them...

On 11/07/18 18:43 +0200, Salvatore D'angelo wrote:
 On Wed, 2018-07-11 at 18:43 +0200, Salvatore D'angelo wrote:
> [...] question is pacemaker install
> /etc/init.d/pacemaker script but its header is not compatible
> with newer system that uses LSB.

Combining LSB and "newer system" in one sentence is sort of ridiculous
since LSB dates back to 2002 (LSB 1.1 seems to be first to actually
explain headers like Default-Start [1]), and the concept of system
initialization in the Linux context was gradually refined with
projects like upstart and systemd.  

What may have changed between older and newer Ubuntu, though,
towards less compatibility (or contrary, more strictness on the
headers/initscript meta-data) is that the compatibility support
scripts/translators are written from scratch, leaving relaxed
approach (the standard is also not that strict) behind ... or not,
and this is just a new regression subsequently fixed later on:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588868

which matches your:

>> 11.07.2018 21:01, Salvatore D'angelo пишет:
>>> [...] system find that sysV is installed and try to leverage on
>>> update-rc.d scripts and the failure occurs:
>>> 
>>> root@pg1:~# systemctl enable corosync
>>> corosync.service is not a native service, redirecting to 
>>> systemd-sysv-install
>>> Executing /lib/systemd/systemd-sysv-install enable corosync
>>> update-rc.d: error: corosync Default-Start contains no runlevels, aborting.

So I'd be inclined to think the existing initscripts can be used just
fine in bug-free LSB initialization scenarios.  It'd be hence just
your choice whether to apply the workaround for sysv-rc bug (?) that
you've presented.

Anyway, as mentioned:

> On 11 Jul 2018, at 18:40, Andrei Borzenkov 
> wrote:
>> 16.04 is using systemd, you need to create systemd unit. I do
>> not know if there is any compatibility layer to interpret
>> upstart configuration like the one for sysvinit.

and

> On 11 Jul 2018, at 21:07, Andrei Borzenkov  wrote:
>> Then you built corosync without systemd integration. systemd will prefer
>> native units.

You shouldn't be using, not even indirectly, initscripts with
systemd-enabled deployments, otherwise you ask for various dependency
mismatches and other complications.

Which gets us to another problem in pacemaker context:

 On Wed, 2018-07-11 at 18:43 +0200, Salvatore D'angelo wrote:
> when I run “make install” anything is created for systemd env.

(presuming anything ~ nothing), because as Ken mentioned:

 On 11 Jul 2018, at 19:29, Ken Gaillot  wrote:
 With Ubuntu 16, you should use "systemctl enable pacemaker" instead
 of update-rc.d.

So, if you haven't tried to build pacemaker on a system differing to
the target one in some build-time important aspects, then I can guess
you just hadn't ensured you have all systemd-related requisities
installed at the time you've run "./configure".  Currently, it boils
down to libdbus-1 library + development files (looks covered with
"libdbus-1-dev" package) & working "systemctl" command from systemd
suite.

Frankly, when people go the path of custom compilations, it's assumed
they will get familiar with the build system tools, or at the very
least will try to make a reason from what's written to the terminal
-- Salvatore, if you were careful enough, you could observe lines
like these if you had all such prerequisites right (alternatively,
review config.log file):

> checking for DBUS... yes
> checking for DBusBasicValue... yes
> checking for systemd version query result via dbus-send... string "238"
> checking whether to enable support for managing resources via systemd... yes
> checking for systemd path for system unit files...  /usr/lib/systemd/system

If there was "no" or "borked" indications with some of these lines,
you can be sure that you didn't satisfy some preconditions for
pacemaker to count on systemd -- service files won't be installed
in that case.  Some (though not all) of these decisions can be
overridden with "./configure  --enable-systemd".

If you observe something not matching the expectations, tell us
_what you've tried_ to get it working as expected (please do not
expect a micro-guidance, since in that case you'll be clearly
better served with distro-provided packages).

Once the pacemaker side is resolved, we can move on to corosync. 

* * *

Btw. I've attempted to get rid of a rather crazy (and now also
apparently error-prone) multi-init-support static deployments
of pacemaker:
https://github.com/ClusterLabs/pacemaker/pull/1175
though it was rejected on dubious grounds (not first, nor last).

Discussing arising ambiguity here, I take the opportunity to solicit
feedback 

Re: [ClusterLabs] What triggers fencing?

[Klaus Wenninger]

On 07/12/2018 09:39 AM, Confidential Company wrote:
> Message: 2
> Date: Wed, 11 Jul 2018 16:33:31 +0200
> From: Klaus Wenninger mailto:kwenn...@redhat.com>>
> To: Ken Gaillot mailto:kgail...@redhat.com>>,
> Cluster Labs - All topics
>         related to open-source clustering welcomed
> mailto:users@clusterlabs.org>>,
>         Andrei Borzenkov  >
> Subject: Re: [ClusterLabs] What triggers fencing?
> Message-ID: <2bf61b9f-98b0-482f-fa65-263ba9490...@redhat.com
> >
> Content-Type: text/plain; charset=utf-8
>
> On 07/11/2018 04:11 PM, Ken Gaillot wrote:
> > On Wed, 2018-07-11 at 11:06 +0200, Klaus Wenninger wrote:
> >> On 07/11/2018 05:48 AM, Andrei Borzenkov wrote:
> >>> 11.07.2018 05:45, Confidential Company ?:
>  Not true, the faster node will kill the slower node first. It is
>  possible that through misconfiguration, both could die, but it's
>  rare
>  and easily avoided with a 'delay="15"' set on the fence config
>  for the
>  node you want to win.
> 
>  Don't use a delay on the other node, just the node you want to
>  live in
>  such a case.
> 
>  **
>  1. Given Active/Passive setup, resources are
>  active on Node1
>  2. fence1(prefers to Node1, delay=15) and
>  fence2(prefers to
>  Node2, delay=30)
>  3. Node2 goes down
> > What do you mean by "down" in this case?
> >
> > If you mean the host itself has crashed, then it will not do anything,
> > and node1 will fence it.
> >
> > If you mean node2's network goes out, so it's still functioning but no
> > one can reach the managed service on it, then you are correct, the
> > "wrong" node can get shot -- because you didn't specify anything about
> > what the right node would be. This is a somewhat tricky area, but it
> > can be done with a quorum-only node, qdisk, or fence_heuristics_ping,
> > all of which are different ways of "preferring" the node that can reach
> > a certain host.
>
>
>
> Or in other words why would I - as a cluster-node - shoot the
> peer to be able to start the services locally if I can somehow
> tell beforehand that my services anyway wouldn't be
> reachable by anybody (e.g. network disconnected).
> Then it might make more sense to sit still and wait to be shot by
> the other side for the case that guy is more lucky and
> has e.g. access to the network.
>
>
> -Klaus
>
>
> in case of 2node setup, they are both know nothing if their services
> are reachable by anybody.

Of course they can not get that knowledge using the cluster-peer but
maybe it is possible to get some additional instance into the game.
As Ken already mentioned that might be a disk, an additional node
just for quorum, qdevice or fence_heuristics_ping.
The latter is used on the same fencing level before your real
fencing device and tries to reach IP-Address(es) you configure
and dependent on that it gains some knowledge in how far the
local node might be accessible from outside.

Btw. in your config I saw that you are using pcmk_delay_max on just
one of the nodes. That is not how it is designed to be used as
you will have a random delay between 0 and max. I would rather
recommend using pcmk_delay_base on one of the nodes (fixed delay)
if you want to prioritize one of them or pcmk_delay_max
with the same delay if you rather want a random behavior.

Unfortunately the current implementation of fencing doesn't
allow things like dynamic location-rules that can react on e.g.
certain resources running as to prioritize the active node.
What you still can do is that you try to go the way fence_heuristics_ping
is going (put something in a fencing hierarchy in front of the real
fencing device) and add a fence-agent that in case the node
has certain resources running (active) would return successfully
immediately and in case they are not running (passive) waits
a certain time before returning successfully.

Otherwise - without checking the logs - I don't know why
disconnecting either node2 or node1 makes a difference.
(Is that reproducible at all?)
In the back of my mind I remember an issue with Corosync
where an interface going down might prevent loss detection
somehow - not remembering exactly.

Regards,
Klaus



>
> Sharing you my config and my tests:
>
> Last login: Thu Jul 12 14:57:21 2018
> [root@ArcosRhel1 ~]# pcs config
> Cluster Name: ARCOSCLUSTER
> Corosync Nodes:
>  ArcosRhel1 ArcosRhel2
> Pacemaker Nodes:
>  ArcosRhel1 ArcosRhel2
>
> Resources:
>  Resource: ClusterIP (class=ocf provider=heartbeat type=IPaddr2)
>   Attributes: cidr_netmask=32 ip=172.16.10.243
>   Operations: monitor interval=30s (ClusterIP-monitor-interval-30s)
>               start interval=0s timeout=20s (ClusterIP-start-interval-0s)
>               stop interval=0s timeout=20s (ClusterIP-stop-interval-0s)
>
> Stonith Devices:
>  Resource: Fence1 (class=stonith type=fence_vmware_soap)
>   

Re: [ClusterLabs] Problem with pacemaker init.d script

[Salvatore D'angelo]

Hi,

I have a cluster on three bare metal and I use two busters nodes to keep 
walking files and backup store on an object store.
I use Docker for test purpose.

Here the possible upgrade scenario you can apply:
http://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/ap-upgrade.html

I used Rolling method or node by node because I always have a master up and 
running (there is few ms of downtime when switch occurs and I have a connection 
pool then immediately switch to the new master).

You need to understand that if if Rolling is only suggested for minor upgrade, 
2.0.0 didn’t introduced anything new, only removed deprecated features + bug 
fix on top of 1.1.18 code.
1.1.19 contains back porting of these fix (but not the remove of deprecated 
features). So you can apply this upgrade method even if you want to move to 
2.0.0. 
We decide to go on 1.1.19. GA code was release two days ago.

Read all threads with my name in June and July here:
https://oss.clusterlabs.org/mailman/listinfo/users

you’ll find useful info I had to solve. 

On each node I do the following:
1. I first download source code for old pacemaker, corosync, crmsh and 
resource agents
2. mae uninstall on all of them
3. download source of new code (I verified on Ubuntu 14.04 library must 
not be upgraded, for 16.04 I just downloaded the new version of the libraries)
4. follow the build instruction for all the 4 projects. Resource agents 
is not documented, I do:
autoreconf -i -v
./configure
make
make install

for the other simply:
./autogen.sh
./configure
make
make install

5.  then do again the configuration steps you did when created the 
cluster with 1.1.14

I used Docker for test because it minimise the test time. If I do something 
wrong and situation is not recoverable I recreate the cluster in minutes.
You can do the same with virtual machine and Vagrant. But I consider this 
critical.

That’s all. 


> On 12 Jul 2018, at 00:31, Casey & Gina  wrote:
> 
>> After I successfully upgraded Pacemaker from 1.1.14 to 1.1.18 and corosync 
>> from 2.3.35 to 2.4.4 on Ubuntu 14.04 I am trying to repeat the same scenario 
>> on Ubuntu 16.04.
> 
> Forgive me for interjecting, but how did you upgrade on Ubuntu?  I'm 
> frustrated with limitations in 1.1.14 (particularly in PCS so not sure if 
> it's relevant), and Ubuntu is ignoring my bug reports, so it would be great 
> to upgrade if possible.  I'm using Ubuntu 16.04.
> 
> Best wishes,
> -- 
> Casey
> ___
> Users mailing list: Users@clusterlabs.org
> https://lists.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
https://lists.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] What triggers fencing?

[Confidential Company]

Message: 2
Date: Wed, 11 Jul 2018 16:33:31 +0200
From: Klaus Wenninger 
To: Ken Gaillot , Cluster Labs - All topics
related to open-source clustering welcomed ,
Andrei Borzenkov 
Subject: Re: [ClusterLabs] What triggers fencing?
Message-ID: <2bf61b9f-98b0-482f-fa65-263ba9490...@redhat.com>
Content-Type: text/plain; charset=utf-8

On 07/11/2018 04:11 PM, Ken Gaillot wrote:
> On Wed, 2018-07-11 at 11:06 +0200, Klaus Wenninger wrote:
>> On 07/11/2018 05:48 AM, Andrei Borzenkov wrote:
>>> 11.07.2018 05:45, Confidential Company ?:
 Not true, the faster node will kill the slower node first. It is
 possible that through misconfiguration, both could die, but it's
 rare
 and easily avoided with a 'delay="15"' set on the fence config
 for the
 node you want to win.

 Don't use a delay on the other node, just the node you want to
 live in
 such a case.

 **
 1. Given Active/Passive setup, resources are
 active on Node1
 2. fence1(prefers to Node1, delay=15) and
 fence2(prefers to
 Node2, delay=30)
 3. Node2 goes down
> What do you mean by "down" in this case?
>
> If you mean the host itself has crashed, then it will not do anything,
> and node1 will fence it.
>
> If you mean node2's network goes out, so it's still functioning but no
> one can reach the managed service on it, then you are correct, the
> "wrong" node can get shot -- because you didn't specify anything about
> what the right node would be. This is a somewhat tricky area, but it
> can be done with a quorum-only node, qdisk, or fence_heuristics_ping,
> all of which are different ways of "preferring" the node that can reach
> a certain host.



Or in other words why would I - as a cluster-node - shoot the
peer to be able to start the services locally if I can somehow
tell beforehand that my services anyway wouldn't be
reachable by anybody (e.g. network disconnected).
Then it might make more sense to sit still and wait to be shot by
the other side for the case that guy is more lucky and
has e.g. access to the network.


-Klaus


in case of 2node setup, they are both know nothing if their services are
reachable by anybody.

Sharing you my config and my tests:

Last login: Thu Jul 12 14:57:21 2018
[root@ArcosRhel1 ~]# pcs config
Cluster Name: ARCOSCLUSTER
Corosync Nodes:
 ArcosRhel1 ArcosRhel2
Pacemaker Nodes:
 ArcosRhel1 ArcosRhel2

Resources:
 Resource: ClusterIP (class=ocf provider=heartbeat type=IPaddr2)
  Attributes: cidr_netmask=32 ip=172.16.10.243
  Operations: monitor interval=30s (ClusterIP-monitor-interval-30s)
  start interval=0s timeout=20s (ClusterIP-start-interval-0s)
  stop interval=0s timeout=20s (ClusterIP-stop-interval-0s)

Stonith Devices:
 Resource: Fence1 (class=stonith type=fence_vmware_soap)
  Attributes: action=off ipaddr=172.16.11.201 login=test passwd=testing
pcmk_host_list=ArcosRhel1 pcmk_monitor_timeout=60s port=ArcosRhel1(Joniel)
ssl_insecure=1
  Operations: monitor interval=60s (Fence1-monitor-interval-60s)
 Resource: fence2 (class=stonith type=fence_vmware_soap)
  Attributes: action=off ipaddr=172.16.11.202 login=test passwd=testing
pcmk_delay_max=10s pcmk_host_list=ArcosRhel2 pcmk_monitor_timeout=60s
port=ArcosRhel2(Ben) ssl_insecure=1
  Operations: monitor interval=60s (fence2-monitor-interval-60s)
Fencing Levels:

Location Constraints:
  Resource: Fence1
Enabled on: ArcosRhel2 (score:INFINITY)
(id:location-Fence1-ArcosRhel2-INFINITY)
  Resource: fence2
Enabled on: ArcosRhel1 (score:INFINITY)
(id:location-fence2-ArcosRhel1-INFINITY)
Ordering Constraints:
Colocation Constraints:
Ticket Constraints:

Alerts:
 No alerts defined

Resources Defaults:
 No defaults set
Operations Defaults:
 No defaults set

Cluster Properties:
 cluster-infrastructure: corosync
 cluster-name: ARCOSCLUSTER
 dc-version: 1.1.16-12.el7-94ff4df
 have-watchdog: false
 last-lrm-refresh: 1531375458
 stonith-enabled: true

Quorum:
  Options:
[root@ArcosRhel1 ~]#

**Test scenario:
Given:
Nodes has two interfaces: (ens192 for corosync traffic / ens224 for esxi
traffic)

a.) Node1=Active and Node2=Passive.
 Action=disconnect ens192 of Node1
Output= Node2 was fenced and shutdown
b.) Node1=Passive and Node2=Active
Action=disconnect ens192 of Node1
Output= Node1 was fenced and shutdown
c.) Node1=Passive and Node2=Active
Action=disconnect ens192 of Node2
Output=Node2 was fenced and shutdown


Thanks,
imnotarobot



>
> If you mean the cluster-managed resource crashes on node2, but node2
> itself is still functioning properly, then what happens depends on how
> you've configured failure recovery. By default, there is no fencing,
> and the cluster tries to restart the resource.
>
 4. Node1 thinks Node2 goes down / Node2 thinks
 Node1 goes
 down
>>> If node2 is down, it cannot think anything.
>> True. Assuming it is not really down but just somehow disconnected
>> for my