Thanks, but no, I wrote in my first email that the behavior was the same with or without lifetime, and with a lifetime of 5mn (P300S), evenif I wait more than 5mn before requesting the second migration, the migration is not executed, the group3 remains stalled on node2 because of first cli-prefer on group2/node2 even if lifetime has expired. (and by the way, I have not the warning messages you mention)
Alain De : Dan Frincu <[email protected]> A : General Linux-HA mailing list <[email protected]> Date : 20/12/2011 11:30 Objet : Re: [Linux-HA] Question or problem around migration Envoyé par : [email protected] 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 _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
