[Linux-HA] Handling colocation constraints with more than 2 entries

Lars Marowsky-Bree lmb at novell.com
Thu Oct 14 08:24:09 MDT 2010


On 2010-10-08T15:08:48, Andrew Beekhof <andrew at beekhof.net> 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. Collocation sets
just don't work as expected, and we should fix that.

> > 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 ;-)

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.

> > 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. 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
;-)

(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?

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




More information about the Linux-HA mailing list