On 08/05/2011 11:26 AM, [email protected] wrote: > Hi, > I was the guy who intiate this thread with a simple question, but > this thread has been re-oriented with other similar questions ... > so I don't know who is answering to anybody else ... please Fabian, > if you can just reopen my first msg in this thread, it would be nice > for me ...
Yes you are right - so I will "rewind" the thread beginning from message 1 :) > Thanks a lot anyway. > Alain > > > > De : Maloja01 <[email protected]> > A : [email protected] > Date : 05/08/2011 11:02 > Objet : Re: [Linux-HA] Antw: Re: location and orders : Question about a > behavior ... > Envoyé par : [email protected] > > > > On 08/05/2011 08:30 AM, Ulrich Windl wrote: >>>>> Maloja01 <[email protected]> schrieb am 04.08.2011 um 18:49 in > Nachricht >> <[email protected]>: >>> Hi Ulrich, >>> >>> I did not folow the complete thread, just jumped in - sorry. Is the >>> resource inside a resource group? In this case the stickiness is >>> multiplied. And sofor the stickiness could be greater than the location >>> role (score). >> >> Hi! >> >> Yes, a group with about 20 resources has a resource-stickiness="100000" > > In this case - if I remeber that correctly the scores for a RUNNING > group is 20*100000 -> 2000000 > 500000. > > Can you describe your problem, what are you missing? > > a) You want to have a RUNNING group NOT to do a fallback -> Stickiness > should do that here: 2M ("active" node) >500K (preferred node) [if > activenode <> preferred node ;-)] > b) You want to have a STOPPED group to be placed on a specific node (to > have an "ordered" administartion at least at the start-point -> location > score should help here 500K (preferred node) >0 (not preferred node) > > I miss the point where you argumented, that stickiness is not > implemented as you expected it would be implemented. Could you explain, > whats missing or wrong? Maybe we can try it in a state description like > status-before (f.e. group on node1), change in the cluster (either event > or admin based) and status-after (here the current implemented one and > the one that you expected how it should work). > > Kind regards > Fabian > > and a "location loc_grp_cbw grp_cbw 500000: node". As the group is > somewhat indivisible, assigning varying stickinesses to individual > resources just makes things unreadable and complicated. I feel that a > group stickyness should override individual resource stickynesses, and > not be used a a default stickyness for every resource in the group. >> >> Regards, >> Ulrich >> >>> >>> Regards >>> Fabian >>> >>> On 08/04/2011 03:10 PM, Ulrich Windl wrote: >>>>>>> Maloja01 <[email protected]> schrieb am 04.08.2011 um 12:58 in > Nachricht >>>> <[email protected]>: >>>>> 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. >>>> >>>> fabian, >>>> >>>> I know that, and the errors were removed by "crm_resource -C". Still > the >>> resource is happy where it is, and doesn't want to move away. >>>> >>>>> >>>>> 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. >>>> >>>> Unfortunately someone did a manual migrate yesterday, so I cannot show > the >>> scores that lead to the problem. >>>> >>>> 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 >>> >> >> >> >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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
