>>> 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-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
