On 08/04/2011 08:28 AM, Ulrich Windl wrote: > Hi! > > Isn't the stickyness effectively based on the failcount? We have one resource > that has a location constraint for one node with a weight of 500000 and a > sticky ness of 100000. The resource runs on a different node and shows no > tendency of moving back (not even after restarts).
No stickiness has nothing to do with the failcount. The policy engine could take both into account the stickiness (for RUNNING resources) and the failcount for (RUNNING or non-running ressources). If you ever had a on-start-failure of a resource on a node the failcount is set to infinity which means, the resource could not be started at this node. If the policy engine needs to evaluate where to run a resource it uses the location/antcolocation/cololaction constraints, failcounts, stickiness and maybe some other scores to evaluate WHERE to run a resource. So in my opinion the stiness does exactly what you are asking for. Kind Regards Fabian > > Somehow the implementation of stickyness is not what one might expect. I'd > expect stickyness to be related to RUNNING resources. I see little sense in > keeping a resource on a node after restarting. > > Why? Usually you want stickyness to prevent unexpected downtimes or negative > side effects caused by migration (e.g. all users loosing their connections). > But as a restart will have these side-effects anyway, I see little sense with > the current implementation. > > Regards, > Ulrich _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
