Re: [Pacemaker] colocation that doesn't

2010-12-09 Thread Andrew Beekhof
On Tue, Nov 30, 2010 at 12:11 AM, Alan Jones wrote: > On Thu, Nov 25, 2010 at 6:32 AM, Tim Serong 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

Re: [Pacemaker] colocation that doesn't

2010-11-30 Thread Alan Jones
I was thinking along the lines of your second suggestion. It involves teaching my "external source" about relationships between resources which I don't like but is possible. A phrase from the '08 election cycle involving lipstick comes to mind ... ;) Thanks for following up Tim! Alan On Mon, Nov 2

Re: [Pacemaker] colocation that doesn't

2010-11-29 Thread Tim Serong
On 11/30/2010 at 10:11 AM, Alan Jones wrote: > On Thu, Nov 25, 2010 at 6:32 AM, Tim Serong 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

Re: [Pacemaker] colocation that doesn't

2010-11-29 Thread Alan Jones
On Thu, Nov 25, 2010 at 6:32 AM, Tim Serong 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 Pacemak

Re: [Pacemaker] colocation that doesn't

2010-11-25 Thread Tim Serong
On 11/25/2010 at 10:33 AM, Alan Jones wrote: > Instead of: > > > > colocation resX-resY -2: resX resY > > > > Try: > > > > colocation resX-resY -2: resY resX > > > > That works fine, as you describe, for placing resY when resX is > limited by the -inf rule; but not the reverse. > In

Re: [Pacemaker] colocation that doesn't

2010-11-24 Thread Alan Jones
> Instead of: > >  colocation resX-resY -2: resX resY > > Try: > >  colocation resX-resY -2: resY resX > That works fine, as you describe, for placing resY when resX is limited by the -inf rule; but not the reverse. In my configuration the -inf constraints come from an external source and I wish p

Re: [Pacemaker] colocation that doesn't

2010-11-23 Thread Tim Serong
On 11/24/2010 at 12:32 PM, Alan Jones wrote: > On Sat, Nov 20, 2010 at 1:05 AM, Andrew Beekhof wrote: > > Then -2 obviously isn't big enough is it. > > I need a value between and not including -inf and -2 that will work. > All the values I've tried don't, so I'm open to suggestions. > >

Re: [Pacemaker] colocation that doesn't

2010-11-23 Thread Alan Jones
On Sat, Nov 20, 2010 at 1:05 AM, Andrew Beekhof wrote: > Then -2 obviously isn't big enough is it. I need a value between and not including -inf and -2 that will work. All the values I've tried don't, so I'm open to suggestions. > Please read and understand: >   > http://www.clusterlabs.org/doc

Re: [Pacemaker] colocation that doesn't

2010-11-20 Thread Andrew Beekhof
On Mon, Nov 15, 2010 at 6:34 PM, Alan Jones wrote: > primitive resX ocf:pacemaker:Dummy > primitive resY ocf:pacemaker:Dummy > location resX-nodeA resX -inf: nodeA.acme.com > location resY-loc resY 1: nodeB.acme.com > colocation resX-resY -2: resX resY > > Both resX and resY end up on nodeB.  I'm

Re: [Pacemaker] colocation that doesn't

2010-11-16 Thread Vadym Chepkov
On Nov 15, 2010, at 2:18 AM, Andrew Beekhof wrote: > On Fri, Nov 5, 2010 at 4:07 AM, Vadym Chepkov wrote: >> >> On Nov 4, 2010, at 12:53 PM, Alan Jones wrote: >> >>> If I understand you correctly, the role of the second resource in the >>> colocation command was defaulting to that of the first

Re: [Pacemaker] colocation that doesn't

2010-11-15 Thread Alan Jones
primitive resX ocf:pacemaker:Dummy primitive resY ocf:pacemaker:Dummy location resX-nodeA resX -inf: nodeA.acme.com location resY-loc resY 1: nodeB.acme.com colocation resX-resY -2: resX resY Both resX and resY end up on nodeB. I'm expecting resY to land on nodeA. Alan On Sun, Nov 14, 2010 at 11

Re: [Pacemaker] colocation that doesn't

2010-11-14 Thread Andrew Beekhof
On Fri, Nov 5, 2010 at 4:07 AM, Vadym Chepkov wrote: > > On Nov 4, 2010, at 12:53 PM, Alan Jones wrote: > >> If I understand you correctly, the role of the second resource in the >> colocation command was defaulting to that of the first "Master" which >> is not defined or is untested for none-ms r

Re: [Pacemaker] colocation that doesn't

2010-11-05 Thread Alan Jones
The attached patch shows how I'm debugged this problem. First enable pengine debug prints by changing the argument to crm_log_init from LOG_INFO to LOG_DEBUG_6. Then you will notice that filter_colocation_constraint() drops the colocation rule because myprim has an "Unkown" role. I then modified th

Re: [Pacemaker] colocation that doesn't

2010-11-05 Thread Pavlos Parissis
On 5 November 2010 04:07, Vadym Chepkov wrote: > > On Nov 4, 2010, at 12:53 PM, Alan Jones wrote: > > > If I understand you correctly, the role of the second resource in the > > colocation command was defaulting to that of the first "Master" which > > is not defined or is untested for none-ms reso

Re: [Pacemaker] colocation that doesn't

2010-11-04 Thread Vadym Chepkov
On Nov 4, 2010, at 12:53 PM, Alan Jones wrote: > If I understand you correctly, the role of the second resource in the > colocation command was defaulting to that of the first "Master" which > is not defined or is untested for none-ms resources. > Unfortunately, after changed that line to: > > c

Re: [Pacemaker] colocation that doesn't

2010-11-04 Thread Alan Jones
If I understand you correctly, the role of the second resource in the colocation command was defaulting to that of the first "Master" which is not defined or is untested for none-ms resources. Unfortunately, after changed that line to: colocation mystateful-ms-loc inf: mystateful-ms:Master myprim:

Re: [Pacemaker] colocation that doesn't

2010-11-04 Thread Dejan Muhamedagic
Hi, On Thu, Nov 04, 2010 at 06:51:59AM -0400, Vadym Chepkov wrote: > On Thu, Nov 4, 2010 at 5:37 AM, Dejan Muhamedagic wrote: > > > This should be: > > > > colocation mystateful-ms-loc inf: mystateful-ms:Master myprim:Started > > > > Interesting, so in this case it is not necessary? > > coloca

Re: [Pacemaker] colocation that doesn't

2010-11-04 Thread Vadym Chepkov
On Thu, Nov 4, 2010 at 5:37 AM, Dejan Muhamedagic wrote: > This should be: > > colocation mystateful-ms-loc inf: mystateful-ms:Master myprim:Started > Interesting, so in this case it is not necessary? colocation fs_on_drbd inf: WebFS WebDataClone:Master (taken from Cluster_from_Scratch) but ot

Re: [Pacemaker] colocation that doesn't

2010-11-04 Thread Dejan Muhamedagic
Hi, On Wed, Nov 03, 2010 at 04:24:07PM -0700, Alan Jones wrote: > I running with Pacemaker 1.0.9.1 and Corosync 1.2.7. > I have a simple config below where colocation seems to have the opposite > effect. > Note that if you force myprim's location then mystateful's Master will > colocate correctly

Re: [Pacemaker] colocation that doesn't

2010-11-04 Thread Vadym Chepkov
On Nov 3, 2010, at 7:24 PM, Alan Jones wrote: > I running with Pacemaker 1.0.9.1 and Corosync 1.2.7. > I have a simple config below where colocation seems to have the opposite > effect. > Note that if you force myprim's location then mystateful's Master will > colocate correctly. > The command I

[Pacemaker] colocation that doesn't

2010-11-03 Thread Alan Jones
I running with Pacemaker 1.0.9.1 and Corosync 1.2.7. I have a simple config below where colocation seems to have the opposite effect. Note that if you force myprim's location then mystateful's Master will colocate correctly. The command I use to force is: location myprim-loc myprim -inf: node-not-t