Hi,
On Tue, Dec 20, 2011 at 11:39 AM, <[email protected]> wrote:
> Hi
>
> I just would like how to manager the behavior described below :
>
> Let's say for the example that we have two nodes in Pacemaker
> configuration, and three groups
> of primitives group1, group2, and group3, and that we have colocation
> constraints such as coloc
> group2 with group1 , coloc group3 with group1.
> Now, let's say that all three groups are started on node1
>
> Let's do the migration command :
> crm resource migrate group2 node2 P300S
> all if working fine, the 3 groups are migrated on node2
> and we can see a cli-prefer in the cib.xml for group2
> now if later we do the command :
> crm resource migrate group3 node1 P300S
> we can see the new cli-prefer in the cib.xml for group3
> but the migration is never executed, it seems that it is
> the first cli-prefer on group2 that prevents the second migration to be
> executed.
> I can say that because if I so the same test but with remove of
> cli-prefer for group2
> before executiong the crm resource migrate group3 node1 P300S, the
> migration
> of the 3 groups back to node1 is effective.
> Note that I also did the same test without lifetime parameter and it is
> the same
> behavior.
>
> So my question:
> is it an already identified (and perphas fixed) bug ?
> or is it a normal behavior and how should we manage this behavior so that
> migration
> requests are always effective ?
Well, after you issued the crm resource move command you might have
seen something similar to this:
WARNING: Creating rsc_location constraint 'cli-standby-all' with a
score of -INFINITY for resource all on cluster2.
This will prevent all from running on cluster2 until the
constraint is removed using the 'crm_resource -U' command or manually
with cibadmin
This will be the case even if cluster2 is the last node in the cluster
This message can be disabled with -Q
Unless you specify a lifetime for the move command, then it's
permanent. Normally lifetime should be set to a value higher than the
time it takes the resources to migrate, otherwise it would remove the
constraint before all of the resources have been started on their
destination, which would cause them to migrate back, so this must be
tested, it depends on your specific scenario.
> (I have the solution, in my example above, to do an crm resource
> unmigrate group2,
> just to remove the cli-prefer, before asking the second migration, because
The lifetime will help in this case.
HTH,
Dan
> I have
> stickyness values which avoids the group2 to move in this case, but is it
> the
> only way and correct way to manage this behavior ?)
>
> Thanks for piece of advice.
> Alain
>
> _______________________________________________
> Linux-HA mailing list
> [email protected]
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
--
Dan Frincu
CCNA, RHCE
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
