On Thu, Oct 14, 2010 at 4:24 PM, Lars Marowsky-Bree <[email protected]> wrote: > On 2010-10-08T15:08:48, Andrew Beekhof <[email protected]> wrote: > >> >> but it doesn't address the original problem that >> >> the shell syntax for colocation constraints switches direction when >> >> you add a third element[1]. >> > Yes, that too should be fixed. >> Another idea, instead of colocation+brackets, add colocation_set and >> use whatever new semantics you prefer. > > But the current shell syntax is, IMNSHO, just broken.
No argument there, but Dejan is saying we can't possibly change it. So I figured the next best thing is to warn whenever someone uses the broken syntax get people using something else. > Collocation sets > just don't work as expected, and we should fix that. Don't look at me, I'm in favor of that too. > >> > I'm just voicing that the whole notion of "ordered" collocation gives me >> > the creeps, and that I'd want to abstract this differently. >> The ordered colocation doesn't go away though, you're just piggy >> backing of ordering somewhere else. > > Yes, but I'd prefer not to expose that at all. I hate the notion of > that. Not to put too fine a point to it, it looks like a half-assed > design ;-) You can't have it both ways. Either constraints have a maximum of two actors, or there is some ordering implied. > > If the shell finds that, I'd rather have that rewritten into distinct > ordering + collocation constraints (which should be possible). > > A lower number of atomic objects in the CIB also reduces testing. Not disagreeing. Quite happy to see a unified construct at the shell level. > >> > Similarly, we could do away with groups now - the shell could have that >> > object, yes, but what else is it than a straightforward resource set >> > that wraps around the primitives? (Just like the group object, just in a >> > different section.) [1] >> > >> > [1] Bonus points if you can figure out how to handle cloned groups then >> > ;-) >> >> Now that we've finally got this sort of thing working nicely and you >> want to rewrite it? >> >> Don't make me hurt you :-) > > You've spoken out against groups several times yourself; a number of > "non-obvious" things we found in the past were due to that. Happily the new ordering code made essentially all of the non-obviousness go away. Or perhaps I'm forgetting some. > And keeping > an eye out for design improvements to the data structure, which might > express themselves in simplified code too, seems like a good thing. > > But yes, since groups and clones have additional properties (e.g., > attribute inheritance), just replacing them with resource sets won't > work. But the general idea is, I think, something to keep thinking about > ;-) Absolutely > (Otherwise we accumulate more and more cruft; we need to be willing to > clean up design over time, and thankfully, XSLT allows us to map old > construct to new forms. That would actually be a benefit of XML, for > once.) > > Maybe we should keep a 1.2/1.4 roadmap of XSL cleanups somewhere? Sure, happy to consider it. > At least Florian wants to preach about that at LPC ;-) > > > 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
