dejanmm at fastmail
Nov 5, 2009, 7:57 AM
Post #7 of 19
(110 views)
Permalink
|
Hi,
On Thu, Nov 05, 2009 at 12:17:56PM +0100, Andrew Beekhof wrote:
> On Thu, Oct 29, 2009 at 2:39 PM, Lars Marowsky-Bree <lmb[at]suse.de> wrote:
> > Hi all,
> >
> > I have a pretty common use case - 4-16 nodes with OCFS2 etc, hosting a
> > ton of Xen/KVM guests.
> >
> > Compacting the OCFS2 setup was pretty easy -
> > http://www.advogato.org/person/lmb/diary.html?start=104 - and that part
> > seems short enough.
> >
> > For each guest, I need an order and collocation constraint with the base
> > resources, which becomes complex and lengthy very quickly. Just to
> > illustrate my point:
> >
> > colocation dummy1-c inf: base-clone dummy1
[repetitive stuff illustrating the point cut]
> > order dummy1-o 0: base-clone dummy1
[again]
> >
> > There's a bunch of open issues (resource_sets not supporting score="0",
> > the crm shell not supporting resource_sets at all), but I'd even more
> > prefer if I didn't have to have both the order and collocation
> > constraints.
> >
> > Could we introduce an "conjoin" dependency which merges both?
>
> What about an ordered=(FALSE|true) attribute for colocation constraints?
>
> first == rsc, then == with-rsc, *-action would be set based on the
> rsc(-with)-role
Would that work?
> I mean, we could create a new construct, but I'm worried it might
> cause (additional) confusion.
I think that such a construct would be useful, but I'm more
inclined to have it at the shell level and that it would actually
have predefined scores, e.g.
conjoin base-clone dummy1 [dummy2 ...]
would expand into those two constraints. No promises yet, since
I'm still not sure how difficult that would be to implement.
Expansion is obviously not a problem, but the other direction may
easily be one. Also, I think I'd prefer to have this as a very
simple and obvious construct, without any extra embelishments as
it has been suggested by Lars below. Simply because I believe
that there are just a few of such order/collocation combinations
which would be used.
"conjoin" sounds sort of funny to me (as a non-native speaker).
And, further, the existing constraints are all nouns, so this one
should be a noun too (though I'd really much prefer verb, but I
guess that it may be too late for that). I think I'll pick that
underused Roget's Thesaurus.
Thanks,
Dejan
> > I don't
> > much care whether this is done at the XML/CIB level, or at the shell
> > level (detect duplication and merge for the shell syntax - the advantage
> > would be that none of the other CIB consumers would need to be taught
> > about it); it should allow, of course, to specify both the ordering and
> > collocation scores.
> >
> > So, I'd imagine that the above could be represented in the shell syntax
> > as:
> >
> > conjoin dummies-dep base-clone {dummy1, dummy2, dummy3, ...} \
> > meta score_collocation=infinity score_order=0
> >
> >
> > This would be an extremely desirable usability improvement, IMNSHO. I
> > welcome your feedback.
> >
> >
> > 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
> >
> >
> > _______________________________________________
> > Pacemaker mailing list
> > Pacemaker[at]oss.clusterlabs.org
> > http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> >
>
> _______________________________________________
> Pacemaker mailing list
> Pacemaker[at]oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
_______________________________________________
Pacemaker mailing list
Pacemaker[at]oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
|
