Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1193090 - typo in manual: odd number should be 2
Summary: typo in manual: odd number should be 2
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: doc-High_Availability_Add-On_Overview
Version: 7.1
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Steven J. Levine
QA Contact: ecs-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-02-16 14:48 UTC by Fred van Zwieten
Modified: 2019-03-06 01:30 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-05-05 20:34:16 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Fred van Zwieten 2015-02-16 14:48:01 UTC
Document URL: 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/High_Availability_Add-On_Overview/ch-operation-HAAO.html#s1-quorumoverview-HAAO

Section Number and Name: 

Describe the issue: 
"In a situation where there is no majority (such as an odd-numbered cluster where one node becomes unavailable, resulting in a 50% cluster split), votequorum can be configured to have a tiebreaker policy, which administrators can configure to continue quorum using the remaining cluster nodes that are still in contact with the available cluster node that has the lowest node ID. "

Suggestions for improvement: 
"In a situation where there is no majority (such as an 2-node cluster where one node becomes unavailable, resulting in a 50% cluster split), votequorum can be configured to have a tiebreaker policy, which administrators can configure to continue quorum using the remaining cluster nodes that are still in contact with the available cluster node that has the lowest node ID. "

Additional information: 
odd-numbered -> 2-node

odd-numbered (3, 5, 7, etc) would be good, from a quorum POV.

Comment 2 Steven J. Levine 2015-02-16 17:18:07 UTC
I'm not certain whether that original phrasing is really incorrect -- if you have an odd-numbered cluster and one node becomes unavailable, that leaves an even number of nodes which can result in a 50% split. In a two-node cluster where one node becomes unavailable, that results in one working node so there's not really a split. The confusion might be in the phrase "becomes unavailable" -- meaning not in communication rather than not operational.

I'll pass this by one of the developers.

Comment 4 Steven J. Levine 2015-02-16 17:23:34 UTC
7.1 is going out the door any day, so I'm moving this to 7.2. But if this does result in a change to the documentation I will push it out when it is ready.

Comment 5 Christine Caulfield 2015-02-17 08:51:02 UTC
The example quoted is doubly incorrect, as you point out. As it's meant to be an example I would keep it simple and state the 2 node case something like this:

"In a situation where there is no majority (such as an 2 node cluster where the internal communication network link becomes unavailable, resulting in a 50% cluster split), ..."

Comment 6 Steven J. Levine 2015-02-17 15:56:30 UTC
I have updated the document -- in time for 7.1 -- as per Comment 5. Thanks Chrissie.


Note You need to log in before you can comment on or make changes to this bug.