On Fri, Mar 23, 2007 at 02:08:17PM +0100, Andrew Beekhof wrote: > > On Mar 22, 2007, at 7:40 PM, Dejan Muhamedagic wrote: > > >On Thu, Mar 22, 2007 at 06:15:41PM +0100, Ragnar Kj?rstad wrote: > >>On Thu, Mar 22, 2007 at 02:05:57PM +0100, Dejan Muhamedagic wrote: > >> > >>>On Thu, Mar 22, 2007 at 02:21:23AM +0100, Ragnar Kj?rstad wrote: > >> > >>BTW: I just noticed that the DTD is also checked into mercury. So > >>which > >>is the authoriative version? mercury or wiki? > > > >i think it's wiki, but i'm really not sure. alan? > > mercurial is
right. is it possible to edit the dtd in wiki? it shouldn't be. > >>> > >>>>The explanation for symmetrical is also not good enough, because > >>>>it's > >> > >>> > >>>>not clear what the "reverse" constraint is. > >> > >>> > >> > >>>sounds clear enough to me, but then it's only me :) > >> > >>The unclear part is that there is 3 things that can be reversed. > >>"x" vs "y", "start" vs "stop" or "before" vs "after". > > > >the first and the last don't make sense. > > > >>I've updated the DTD to specifically state that it is the action and > >>type that is reversed in the symmetrical rule. > >> > >>[...] > >> > >> > >>> > >>>>http://wiki.linux-ha.org/v2/dtd1.0/annotated#head-390c0a5ecce666978dab397e20d1575ff366c262 > >> > >>> > >>>> > >> > >>> > >>>>needs to explain if "x colocated with y" means the same thing as "y > >> > >>> > >>>>colocated with x" or not. > >> > >>> > >> > >>>i believe that it should, but i'm not really sure. anybody? > >> > >>> > >> > >>> > >>>>Is it correct that > >> > >>> > >>>><rsc_colocation id="foo" from="x" to="y" score="INFINITY"/> > >> > >>> > >>>>affects the score of x, but not y. > >> > >>> > >>>> > >> > >>> > >>>>Does that mean that y will be placed first, and x will follow? > >> > >>> > >> > >>>no. it just means that they stay together. > >> > >>> > >> > >>> > >>>>What if y is placed on a node where x fails to start, will both x > >>>>and y > >> > >>> > >>>>be migrated to another node? > >> > >>> > >> > >>>yes. there were some changes though in 2.0.8 to make heartbeat > >> > >>>more configurable here and to make it possible to stop one > >> > >>>resource and leave the other in the started state, given that the > >> > >>>order constraint is right. > >> > >>Interesting. Any more information? > >>The changelog includes > >> + Support weak and uni-directional collocation constraints (FATE > >> 300792). > >>but I see no mention of "weak" or "uni-directional" in the DTD or > >>anywhere else in the documentation. > > > >unfortunately our master of crm is not available right now. i'll > >try to explain what it is about: a group of resources or an > >ordered set of resources used to behave like a unit. one of them > >goes down, the others follow. that hasn't been quite right, > >because one would expect those resources which are "under" (in > >terms of order, started before) to keep running. in other words, a > >colocation should mean that the two things, if they run, must run > >on the same node, but it should not imply that they depend on each > >other. that was particularly important for non-grouped resources, > >because one common scenario is that two resources which are > >independent of each other both depend on a third one. > > > >i'm afraid that the documentation hasn't been updated. > > > >> > >>> > >>>>What is the best practise use of colocation? > >> > >>> > >> > >>>not sure if i understand this. basically, you just use them where > >> > >>>you need them. hmm, that sounds stupid, but don't see any other > >> > >>>way to say it :) > >> > >>I should probably be more explisit: > >>In an example with resource A(filesystem), B(database), C(webserver) > >>where A must be started before B before C on the same host. What > >>would > >>the natural colocation rules be? > > > >you're talking about order here. one can only assume that ABC > >should run on the same host. > > > >>I assume one colocation rule between A and B. Does the direction > >>matter? > > > >no. > > it does > > A -> B also says that B can run if A cant, but if B cant run then A > cant either. oops. that's overloading collocations, isn't it. i thought that the "this can run independently of the other" would have been governed by an additional ordering constraint. sth like: - A and B are collocated - A starts before B then we can assume that B depends on A to run. wouldn't that be more logical? if the user doesn't give an ordering constraint, then the two are independent of each other, but probably depend on some third resource. in which case it should be ok not to mess with the one in case the other leaves. > if you want neither to run if the other cant... then there is some > option to allow this (but i forget what its called) > > > > > > >>What about C - does it matter if the rule colocates it with A or B > >>since > >>they must both be running on the same system anyway? > > > >no. > > > >you should be able to say that A and B should run on the same > >node, ditto for B and C, and a rule for A and C will be implied. > >if it doesn't, then we have a bug. > > > >> > >>> > >>>>What about colocation rules with -INFINITY score - are they > >>>>assymetrical > >> > >>> > >>>>as well? > >> > >>> > >> > >>>asymmetrical? they just say that two resources are not to be run > >> > >>>on the same node. then scores decide what happens. > >> > >>Well, I assumed that there were some subtile difference between > >>"A colocate B score INFINITY" and "B colocate A score INFINITY". But > >>maybe I was wrong about this? > >> > >>But my question was if "A colocate B score -INFINITY" is the same > >>as "B > >>colocate A score -INFINITY". > > > >yes. > > no - see above hmm, could you please elaborate on this one. this is saying that the two resources are not to run on the same host. then, if we our out of nodes, the scores should be calculated to see which matters more, no? > >>If the colocation rules are all bi-directional and it doesn't matter > >> > > they're not > > > > >>what order it is specified in it's pretty simple, but belive Alan > >>explained it wasn't that simple. > > > >alan? > > > >>-- > >>Ragnar Kj?rstad > >>Software Engineer > >>Scali - http://www.scali.com > >>Scaling the Linux Datacenter > > > >-- > >Dejan > >_______________________________________________ > >Linux-HA mailing list > >Linux-HA@lists.linux-ha.org > >http://lists.linux-ha.org/mailman/listinfo/linux-ha > >See also: http://linux-ha.org/ReportingProblems > -- Dejan _______________________________________________ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
