>>> On Fri, Apr 20, 2007 at 10:05 PM, in message <[EMAIL PROTECTED]>, "Andrew Beekhof" <[EMAIL PROTECTED]> wrote: > If rsc_colocation and rsc_location were the same then we wouldn't need > two names, but they are different and behave accordingly.
I suppose I'm struggling with the fact that apply -INFINITY rsc_location constraints can make a resource unable to run anywhere, whilst +INFINITY can't do that. This alone makes them inexact inverses. -> unintuitive. but I suppose as Alan said, "it's an idiom, learn it!" > > If anything, rsc_colocation would be changed to be more like > rsc_location but there are technical and cognitive limitations that > currently prevent this. whatever happens here, I hope you agree we _must_ keep the ability to force two resource to colocate, or fail (at least one) to run. > > The idea of having +INFINITY (in the context of rsc_location) mean a > resource can _only_ run on that node is more than slightly absurd for > a _high_availability_ project. mmm. I do see your point. From that point of view, having to specify a number of -INFINITY resources it fine by me. > > Perhaps thats why I rarely need to explain this - because very few > people want to add resources that run only on one node. It also > sounds like you should be using symmetric_cluster=false as that seems > more appropriate for the type of cluster you're building. Not sure about that. I still have about 18 resources that should be treated symmetrically, and only 1 that doesn't. In that case, which should win? > > > On 4/20/07, Yan Fitterer <[EMAIL PROTECTED]> wrote: >> >>> On Fri, Apr 20, 2007 at 3:42 PM, in message >> <[EMAIL PROTECTED]>, "Andrew Beekhof" >> <[EMAIL PROTECTED]> wrote: >> > On 4/20/07, Yan Fitterer <[EMAIL PROTECTED]> wrote: >> >> >> In the attached pe- warn, why is resource R_audit being started on >> >> >> idm01 when there is an INFINITY constraint with uname eq idm04? >> >> >> >> >> >> BTW - idm04 is in standby at the moment. That should hardly matter. >> >> >> I >> >> >> expect the resource to be "cannot run anywhere". >> >> >> >> >> >> I really hope it's not a typo, but I have read it as much as I can, >> >> >> and I can't see it... >> >> >> >> >> >> Thanks Yan >> >> > >> >> > So, there is only one place it can be run, and it has score 0. (It >> >> > can't run on a machine in standby). >> >> > >> >> > So, it gets run there. >> >> > >> >> > What's the problem? >> >> >> >> The problem is that I need the resource to _ONLY_ run on IDM04, or not at >> > all. Yes, I know, this is not clustering, or HA, but there is a good > reason. >> >> >> >> If you want the long story, the reason for that is that resource R_audit > (an >> > instance of Novell Audit) is not meant to be clustered here, but depends on >> > resource R_workforce_edir (eDirectory instance), which IS clustered. The >> > issue is that Novell Audit must start after eDirectory (Audit configuration >> > is stored in eDir). So the best way I could think of achieving that, was to >> > created a resource for Audit, with an order constraint between eDirectory > and >> > Audit. But since Audit isn't really clustered (executables on one node > only), >> > I need to make it run on IDM04, or nowhere. That what I thought INFINITY >> > would mean. >> >> >> >> If - INFINITY achieves that, but INFINITY doesn't, then it looks like >> >> broken >> > logic to me, where INFINITY is not the exact opposite of - INFINITY. If >> > this > is >> > really "works as designed", it is very highly counter- intuitive, and IMHO >> > should be considered a bug. >> >> >> >> Actually, INFINITY in colocation constraints _does_ mean, "work here or >> > nowhere". Why would it be different for location constraints? >> > >> > because there is no concept of if you can't run with rscX, try rscY >> > and then rscZ. >> > >> > ideally that might be nice capability to have, but we don't allow that >> > in order to make resource placement solvable. >> > >> > >> > "symmetric_cluster=true & - INFINITY" >> > is the inverse of >> > "symmetric_cluster=false & +INFINITY" >> > >> > >> > if you say: symmetric_cluster=true >> > then you're saying resources can run anywhere by default. >> > if there is somewhere a resource can't run, then you have to >> > explicitly say so with - INFINITY. >> > >> > its the reverse of symmetric_cluster=false, where resources can't run >> > anywhere by default and you need explicitly say where they can run. >> > >> > >> > this particular aspect of configuration has been documented for a long >> > time, but perhaps Alan would feel better if it was added to his idioms >> > document as well. >> > >> > >> > sure, we could make >> > rsc_location(rscX, nodeX, INFINITY) >> > also modify >> > node in ( [nodes] - nodeX ) >> > >> > but then if you say: >> > rsc_location(rscX, nodeX, INFINITY) >> > rsc_location(rscX, nodeY, 10000) >> > rsc_location(rscX, nodeZ, 100) >> > >> > then it cant still only ever run on nodeX, because - INFINITY+10000 ::= >> > - INFINITY >> >> All this makes perfect sense, just as long as one forgets that with the > current design, INFINITY and - INFINITY: >> >> - aren't exact inverses >> - don't behave in the same way depending on the context (colocation vs > location for ex) >> - sound pretty absolute, but aren't. >> - do "what is says on the tin" only sometimes (i.e. INFINITY is >> intuitively > expected to be absolute, whether negative of positive) >> >> Another problem with not being able to positively restrict a resource to a > node (or set of), is that it will again not be intuitive (and safe!) behavior > when adding new nodes to existing cluster(s). >> >> This doesn't feel to me like a sustainable long- term solution, even though >> I > can follow all the arguments (and agree that they are valid too...) that > underpin the current way of working. >> >> How many times, Andrew, can you bear to explain this to people like me? Even > assuming I'm dimmer than most, there will still be plenty to waste everbody's > time getting their nose bloodied with something that requires extensive study > of the various design implications of resource placement computations to > grasp correctly. >> >> I for one, have read most of the INFINITY / - INFINITY debate, but it is > intricate enough that simply reading about it without the practice meant that > the exact details were quickly forgotten. I simply couldn't believe that a > premise as obvious as "INFINITY location constraint => run here and nowhere > else" would be false. >> >> I do hope this will be on the list of things to be addressed at some point > in the future - I still think it's broken. >> >> Yan >> >> >> >> _______________________________________________ >> Linux- HA mailing list >> Linux- [EMAIL PROTECTED] ha.org >> http://lists.linux- ha.org/mailman/listinfo/linux- ha >> See also: http://linux- ha.org/ReportingProblems >> > _______________________________________________ > Linux- HA mailing list > Linux- [EMAIL PROTECTED] ha.org > http://lists.linux- ha.org/mailman/listinfo/linux- ha > See also: http://linux- ha.org/ReportingProblems _______________________________________________ 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
