On Fri, Oct 08, 2010 at 08:27:45AM +0200, Andrew Beekhof wrote: > On Thu, Oct 7, 2010 at 5:49 PM, Lars Marowsky-Bree <[email protected]> wrote: > > On 2010-10-05T18:03:17, Andrew Beekhof <[email protected]> wrote: > > > >> > Anyway, it's too late to change the semantics as > >> > that would change behaviour of the existing clusters. > >> Actually the solution is really quite easy. > >> > >> 1. Make constraints with > 2 elements and no/insufficient brackets > >> produce a warning and require user confirmation. > >> There is certainly precedent for things in the shell becoming warnings > >> that weren't previously. > >> > >> 2. Decide on two types of brackets to use, one for ordered and one for > >> unordered. > > > > Admittedly, I find the whole notion of "ordered" collocation extremely > > annoying, and unclean design. I'd much rather not have the shell support > > that at all. > > > > That collocation is expressed in what amounts to the reverse of the > > "natural" consequence of ordering is a bit confusing, but I'm afraid > > we're stuck with that now. > > No, we're not. > > > > > > > For order + colocation, a rather common combination of constraints, what > > I'd rather have the shell do is detect a match between them and merge > > them in the shell syntax - there's no reason why a shell statement > > _must_ only expand to a single XML element. > > > > So: > > > > order foo inf: a b > > colocation bar inf: b a > > > > would be merged to > > > > join foo: inf: a b > > > > in the shell. And then do the same for sets; it's not much more > > difficult, and we'll all be much cleaner off than with trying to > > remember what the heck [] () {} were about. And keep it at one set of > > parenthesis. > > I don't see what one has to do with the other. > I'd be in favor of the join construct above (although I'd probably > call it "depends"), but it doesn't address the original problem that > the shell syntax for colocation constraints switches direction when > you add a third element[1].
Which is bad. At the time, there was this bit about group semantics for resource sets, etc, so I expected that it would be better to keep it as it is in the XML. > Or do you imagine that no-one will ever use colocation constraints > ever again once "join" exists? Of course, shell must support single elements as well, as it may happen that there's no sufficiently clean match for a combined expression. Which is also a good thing, since it may attract attention of the user that there might be something wrong in the configuration. > [1] Note that the XML syntax has no "direction" for colocation > constraints without sets. Well, it does, just coded as different attributes. Or did I misunderstand? Thanks, Dejan > > (Add an expand command to turn the automated merge of if people want to > > etc etc, but you get the idea.) > > > > > > > > Regards, > > Lars > > > > -- > > Architect Storage/HA, OPS Engineering, Novell, Inc. > > SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) > > "Experience is the name everyone gives to their mistakes." -- Oscar Wilde > > > > _______________________________________________ > > 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
