[Pacemaker] colocation that doesn't

Andrew Beekhof andrew at beekhof.net
Thu Dec 9 05:20:22 EST 2010

On Tue, Nov 30, 2010 at 12:11 AM, Alan Jones <falancluster at gmail.com> wrote:
> On Thu, Nov 25, 2010 at 6:32 AM, Tim Serong <tserong at novell.com> wrote:
>> Can you elaborate on why you want this particular behaviour?  Maybe
>> there's some other way to approach the problem?
> I have explained the issue as clearly as I know how.  The problem is fundamental
> to the design of the policy engine in Pacemaker.  It performs only two passes to
> resolve constraints, when what is required for general purpose
> constraint resolution
> is an iterative model.  These problems have been addressed in the literature for
> decades.

Theory has the wonderful property of not being impacted by the real world.
Sure we could generate optimum results with an A* algorithm that
searched the solution space for an unbounded time (assuming one
doesn't get stuck in a local optima) before recovering the cluster.
Strangely people want faster recovery than that, so we use a linear
algorithm - and sometimes that requires tradeoffs.

One of those tradeoffs is that _optional_ constraints may be ignored
in some circumstances.
They're best-effort.  This is very clearly documented.

Had you written:
  colocation resX-resY -2: resY resX
then it would have given you the result you wanted.

More information about the Pacemaker mailing list