[Linux-HA] Handling colocation constraints with more than 2 entries
andrew at beekhof.net
Thu Oct 14 09:13:12 MDT 2010
On Thu, Oct 14, 2010 at 4:24 PM, Lars Marowsky-Bree <lmb at novell.com> wrote:
> 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.
>> > 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
> 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.) 
>> >  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
> (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
> 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 ;-)
> 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
> Linux-HA at lists.linux-ha.org
> See also: http://linux-ha.org/ReportingProblems
More information about the Linux-HA