Thanks, but unfortunately, the -U is valuable for a unique -r resource name, so we'll have to execute the crm_resource --un-migrate for each resource, so that's the same solution that I found but with crm instead of crm_resource : crm resource unmigrate group2 The problem is that I give an example with only 3 groups , but when the configuration includes around ten groups collocated, this is not really an easy and quick workaround ...
Alain De : "Ulrich Windl" <[email protected]> A : <[email protected]> Date : 20/12/2011 11:01 Objet : [Linux-HA] Antw: Question or problem around migration Envoyé par : [email protected] >>> <[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 _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
