On Tue, Nov 30, 2010 at 12:11 AM, Alan Jones falanclus...@gmail.com wrote:
On Thu, Nov 25, 2010 at 6:32 AM, Tim Serong tser...@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
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
On Thu, Nov 25, 2010 at 6:32 AM, Tim Serong tser...@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
On 11/30/2010 at 10:11 AM, Alan Jones falanclus...@gmail.com wrote:
On Thu, Nov 25, 2010 at 6:32 AM, Tim Serong tser...@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
On 11/25/2010 at 10:33 AM, Alan Jones falanclus...@gmail.com 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.
On Sat, Nov 20, 2010 at 1:05 AM, Andrew Beekhof and...@beekhof.net 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:
On 11/24/2010 at 12:32 PM, Alan Jones falanclus...@gmail.com wrote:
On Sat, Nov 20, 2010 at 1:05 AM, Andrew Beekhof and...@beekhof.net 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,
On Mon, Nov 15, 2010 at 6:34 PM, Alan Jones falanclus...@gmail.com 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 Nov 15, 2010, at 2:18 AM, Andrew Beekhof wrote:
On Fri, Nov 5, 2010 at 4:07 AM, Vadym Chepkov vchep...@gmail.com 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
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
On Fri, Nov 5, 2010 at 4:07 AM, Vadym Chepkov vchep...@gmail.com 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
On 5 November 2010 04:07, Vadym Chepkov vchep...@gmail.com 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
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 the
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 use
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.
On Thu, Nov 4, 2010 at 5:37 AM, Dejan Muhamedagic deja...@fastmail.fm 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
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 deja...@fastmail.fm wrote:
This should be:
colocation mystateful-ms-loc inf: mystateful-ms:Master myprim:Started
Interesting, so in this case it is not necessary?
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
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:
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:
20 matches
Mail list logo
