On Wed, Jun 16, 2010 at 10:29 AM, Dejan Muhamedagic <deja...@fastmail.fm> wrote: > Hi, > > On Wed, Jun 16, 2010 at 08:55:26AM +0200, Andrew Beekhof wrote: >> On Tue, Jun 15, 2010 at 9:41 PM, Dejan Muhamedagic <deja...@fastmail.fm> >> wrote: >> >> > colocation not-together -inf: d1 d2 d3 >> >> I think there is a problem with this syntax, particularly for +inf. >> >> Consider: >> colocation together1 inf: d1 d2 >> >> This means d1 must run where d2 is. >> >> But if I add d3: >> colocation together1 inf: d1 d2 d3 >> >> Now the original constraint is reversed and d2 must run where d1 is >> (think of how groups work). >> (Unless you're modifying the order). > > No, the order is not modified. > >> I think we need: >> no brackets: exactly 2 resources must be specified >> () brackets: a non-sequential set >> [] brackets: a sequential set > > I thought that the sets were supposed to reduce the number of > constraints and to be used in case more than three resources > involved. That's why there's no special notation for the > sequential sets: there would be simply more than two resources. > > If we adopt the above notation, is there a semantic difference > between these two: > > order o1 <sc>: p1 p2 > order o2 <sc>: [ p2 p1 ] > > or these two: > > collocation c1 <sc>: p2 p1 > collocation c2 <sc>: [ p1 p2 ]
They'd effectively do the same thing, but the first form would always result in a "normal" constraint, the second always a set. _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
