>>> <[email protected]> schrieb am 20.12.2011 um 10:39 in Nachricht
<of861286f8.251ce7d6-onc125796c.0033e7ec-c125796c.00358...@bull.net>:
> 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 ?
The man page for "crm_resource" says:
--un-migrate, -U
Remove all constraints created by -M
Maybe that answers your question.
> or is it a normal behavior and how should we manage this behavior so that
> migration
> requests are always effective ?
> (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
> 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 ?)
That's what I think is necessary.
However I think if you have two nodes available and migrate from A to B, and
then from B to A, CRM should be smart enough to remove the older (conflicting)
constraint, or say that further migration is not possible.
Regards,
Ulrich
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
