Bug 1311749

Summary: document and validate constraint options better
Product: Red Hat Enterprise Linux 7 Reporter: Ken Gaillot <kgaillot>
Component: doc-High_Availability_Add-On_ReferenceAssignee: Steven J. Levine <slevine>
Status: CLOSED DUPLICATE QA Contact: ecs-bugs
Severity: low Docs Contact:
Priority: unspecified    
Version: 7.2CC: abeekhof, cluster-maint, ecs-bugs, jkortus, mnovacek, rhel-docs, slevine, tojeline
Target Milestone: rcKeywords: Documentation
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1302788
: 1376472 (view as bug list) Environment:
Last Closed: 2016-09-15 14:01:14 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1302788    
Bug Blocks: 1376472    

Description Ken Gaillot 2016-02-24 21:43:25 UTC
+++ This bug was initially created as a clone of Bug #1302788 +++

--- Additional comment from Ken Gaillot on 2016-02-04 16:07:04 EST ---

The syntax and documentation for colocation sets is quite confusing (even to me). I will work on the documentation, but to clarify for this case, this is my understanding:

* require-all=false is meaningful only for ordering sets, not colocation sets, so it is irrelevant here

* a colocation set with sequential=false, counterintuitively, does not add any colocation dependency between the items in that set. Instead, it allows the set to be in a colocation constraint with other sets, without its members being affected by each other. Therefore, it only makes sense if there is another set in the constraint.


A constraint like your first one, of the form:

  colocation set A B C sequential=false

is a null statement, with no effect.


A constraint like your second one, of the form:

  colocation set A B C sequential=false set D

means that A, B, and C must be colocated with D, but A, B, and C do not have any explicit relationship with each other (so any of them can fail without affecting the others).


Also, there is always some confusion between ordering constraints and colocation constraints. Colocation of "A with B" (including the colocation set equivalent) means that B will be assigned to a node first, but that does not mean that B will necessarily be started first. Without a separate ordering constraint, A and B may be started simultaneously (or even in reverse order) -- it just will be guaranteed to be on the same node.

I'll clone this BZ for pcs so we can have it reject require-all=false for colocation sets, and reject colocation sets with sequential=false unless there is another set in the constraint.

--- For pcs:

The pcs help text and command validation for pcs constraint using set should be updated per the upstream documentation for resource sets: http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Explained/index.html#s-resource-sets , namely:

Order set does not support the role option, its require-all option can only be used if sequential=false is also used, and sequential=false should be accepted only if there are multiple sets listed in the same constraint.

Colocation set does not support the require-all or action options, and sequential=false again should be accepted only with multiple sets.

It may also be worthwhile to add a location set command. Upstream supports resource sets in location constraints, though they are mentioned only briefly in the documentation and are rarely used. Only role is a valid option there.

Comment 2 Steven J. Levine 2016-02-24 23:14:39 UTC
This is more extensive and provides a lot more info, but it's sort of a duplicate of BZ#1121128. I may close that one as a duplicate of this, since all the info is here.

Comment 4 Steven J. Levine 2016-05-13 18:02:33 UTC
*** Bug 1121128 has been marked as a duplicate of this bug. ***

Comment 6 Steven J. Levine 2016-09-15 14:01:14 UTC
This bz was cloned from 1302788 but provides the same info. I'm closing this as a duplicate of that BZ. (This may have been an administrative error in an attempt to clone this for rhel 6, which I have done separately).

*** This bug has been marked as a duplicate of bug 1302788 ***