Hi, On Thu, Jan 08, 2009 at 10:50:27AM -0800, Joe Bill wrote: > On Wed, Jan 7, 2009 at 14:49, Dejan Muhamedagic <dejanmm[at]fastmail.fm> > wrote: > > Most of you are probably back from holidays, so now may be good > > time to give you some food for thought. > > Happy to oblige. > > >1. Detach monitor operations from primitives > >old (one statement): > ... > >new (three statements): > > Why the "params" keyword in the new syntax ?
Because there are also meta attributes. In the very beginning, I tried to make it work without the "params" keyword, but for some reason I can't recall anymore it didn't work. > Agree for the number of statements, but keep the old, unambiguous syntax like > this: > > primitive drbd0 drbd drbd_resource=drbd0 > monitor drbd0 role=Master interval=59s timeout=30s > monitor drbd0 role=Slave interval=60s timeout=30s > > Strongly suggest to support *both* syntaxes. Of course, both will be supported. > >2. Shorter specification of boolean variables > > Seems more cosmetic to me but have no reason to oppose. > Again strongly support *both* syntaxes. > > CAUTION: Do not mix keyword lists (a la xml) and language constructs. > > "not globally-unique" : NOK > > "!globally-unique" : OK, preferred over above Well, these are the same, some people of course do prefer '!' over 'not', but I still believe that most of the users are not programmers, so I assumed that they'd appreciate 'not' rather than C syntax. > "not-globally-unique" : OK This is an interesting proposition, but probably hard and error prone to do right. > > 3. New "prefer" statement/clause for location preference > > > >old: > >location ms-drbd0-master-on-xen-1 ms-drbd0 rule role=master 100: #uname eq > >>xen-1 > >new: > >prefer ms-drbd0:Master xen-1 # score 100 is implied > > Ok, but support also: > > prefer ms-drbd0 on=xen-1 role=master # score 100 is implied > > ... and combinations like: > > prefer ms-drbd0:master on=xen-1 ... or ... > prefer ms-drbd0 xen-1 role=master That should be covered by the location statement. The new prefer statement would be only for simple location preferences, i.e. node plus score [plus role]. > >new1 (two statements): > >group g1 global-ip web-server > >prefer g1 node1 > >new2 (one statement): > >group g1 global-ip web-server prefer node1 > > > > Agree with the two-statement. > > Disagree with the one-statement. > Ambiguous. Represents an unspecified language construct. > Creates a name exception to handle the nature of this language construct. > > How do you parse, what rules used to parse: > > group g1 global-ip prefer prefer node1 > > group g1 global-ip prefer node1 > > group g1 global-ip web-server prefer prefer The prefer keyword would of course be reserved. Too bad for people naming nodes "prefer" ;-) > >4. Shorter specification of colocation constraints > > > >old: > >colocation apache-group-on-ms-drbd0 inf: apache-group ms-drbd0:Master > >colocation apache-not-with-slave -inf: apache-group ms-drbd0:Slave > > Ugh. Definitely needed. > > I apologize in advance, I really looked everywhere but may have > overlooked this, exactly which HA facility accepts this > "colocation" command with this syntax ? This post is all about the new crm shell and configuration utility which is available as of pacemaker 1.0. Sorry for not being more precise: When I wrote "old" in the original post, I definitely didn't mean "obsolete". The "old" syntax will be kept. > >new: > >colocate apache-group ms-drbd0:Master # inf is implied > >separate apache-group ms-drbd0:Slave # -inf is implied > > Unfortunately, ambiguous. The first one should mean: keep the two together, the second: separate the resources. How exactly ambiguous? > Also, "colocate" and "separate" not the best words to describe > the actions I understand they are supposed to undertake. I looked through the Roget's for ages and could find anything better for collocate. Any suggestions? I'm all ears :) Thanks, Dejan > > > > > _______________________________________________ > 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
