Re: [Pacemaker] RFC: Compacting constraints
On 2009-11-12T14:41:49, Andrew Beekhof wrote: > On Wed, Nov 11, 2009 at 3:12 PM, Lars Marowsky-Bree wrote: > > On 2009-11-11T14:46:02, Lars Marowsky-Bree wrote: > > > >> I went through the possible associations here, and I realize that > >> "conjoin" is a rare word in English. In theory though, "conjoin" more > >> readily implies an order/merge thing going on compared to "coordinate". > >> > >> If one wants to be more clear, "with_after", "along_with" would work > >> too. But I thought "conjoin" was more, well, compact ;-) > > > > Some further thoughts on the bike shed's color - "join", "connect", > > "link". > > Did you create a bug for all this? I've found bugzilla to be quite annoying for discussions, so I first wanted to discuss if/what/how to go about this before filing an enhancement bugzilla. Since we've not yet quite agreed whether this should be a shell macro, or a new CIB construct (despite me of course having the right answer ;-), I wasn't sure we were at the enhancement request stage yet ... I'll go ahead and file that though. 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@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Re: [Pacemaker] RFC: Compacting constraints
On Wed, Nov 11, 2009 at 3:12 PM, Lars Marowsky-Bree wrote: > On 2009-11-11T14:46:02, Lars Marowsky-Bree wrote: > >> I went through the possible associations here, and I realize that >> "conjoin" is a rare word in English. In theory though, "conjoin" more >> readily implies an order/merge thing going on compared to "coordinate". >> >> If one wants to be more clear, "with_after", "along_with" would work >> too. But I thought "conjoin" was more, well, compact ;-) > > Some further thoughts on the bike shed's color - "join", "connect", > "link". Did you create a bug for all this? ___ Pacemaker mailing list Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Re: [Pacemaker] RFC: Compacting constraints
On 2009-11-11T14:46:02, Lars Marowsky-Bree wrote: > I went through the possible associations here, and I realize that > "conjoin" is a rare word in English. In theory though, "conjoin" more > readily implies an order/merge thing going on compared to "coordinate". > > If one wants to be more clear, "with_after", "along_with" would work > too. But I thought "conjoin" was more, well, compact ;-) Some further thoughts on the bike shed's color - "join", "connect", "link". 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@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Re: [Pacemaker] RFC: Compacting constraints
On 2009-11-06T22:13:32, Colin wrote:
> > conjoin dummies-dep base-clone {dummy1, dummy2, dummy3, ...} \
> > meta score_collocation=infinity score_order=0
>
> Suppose we allow regular expressions:
>
> order dummy(\d+)-o 0: base-clone dummy#1
>
> (Where \d is a digit, and #1 inserts the string that matched the first
> bracketed sub-regular-expression from the "other" resource name...
>
> Just thinking out loud, regexes could make so many things shorter...
Woah, you've just officially scared me. ;-)
The problem with your example of course is that it is not clear what to
iterate over. In the above, there's no dummy\d+-o to match yet; in fact,
that is what you'd want to create. So in theory, you'd want this the
other way around - match on the dummy\d+ resource reference and expand
the order constraint from that, which doesn't work well with XML. So, I
think the expansion is right out, because this would never be gotten
right.
If you're saying to allow regex - or at least basic shell pattern -
matching in a resource reference, say a resource set - where actually
each set expands to many resources anyway, now that would possibly be a
clean syntax extension.
ie:
order dummy-o: base-clone (dummy[0-9]+)
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@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Re: [Pacemaker] RFC: Compacting constraints
On 2009-11-05T22:34:32, Tim Serong wrote: > > > "conjoin" sounds sort of funny to me (as a non-native speaker). > > Equally so to me, and Australian is kinda like english. > How about "coordinate"? I went through the possible associations here, and I realize that "conjoin" is a rare word in English. In theory though, "conjoin" more readily implies an order/merge thing going on compared to "coordinate". If one wants to be more clear, "with_after", "along_with" would work too. But I thought "conjoin" was more, well, compact ;-) 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@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Re: [Pacemaker] RFC: Compacting constraints
On 2009-11-05T12:17:56, Andrew Beekhof wrote:
> > Could we introduce an "conjoin" dependency which merges both?
> What about an ordered=(FALSE|true) attribute for colocation constraints?
That sucks completely, IMHO. I already hate the "sequential" attribute
in resource_sets passionately (it's named differently than everywhere
else ("order")), and it muddles up the distinction between order and
placement which is fundamental to the whole constraint design.
Why add it to the collocation, why not to ordered? Maybe make both of
them go away? Yuck! This is the design police, you've just been ticketed
;-)
Also, this wouldn't allow different scores for the order/colocation
constraints easily, which is, for example, needed for primitives
depending on clones.
The shell having a higher abstraction level than the CIB, on the other
hand, now that makes sense to me, so compacting the representation of
CIB elements there strikes me as useful.
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@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Re: [Pacemaker] RFC: Compacting constraints
On Fri, Nov 6, 2009 at 10:13 PM, Colin wrote:
>> conjoin dummies-dep base-clone {dummy1, dummy2, dummy3, ...} \
>> meta score_collocation=infinity score_order=0
>
> Suppose we allow regular expressions:
>
> order dummy(\d+)-o 0: base-clone dummy#1
>
> (Where \d is a digit, and #1 inserts the string that matched the first
> bracketed sub-regular-expression from the "other" resource name...
/me runs
___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Re: [Pacemaker] RFC: Compacting constraints
On 11/6/2009 at 05:13 AM, Andrew Beekhof wrote: > On Thu, Nov 5, 2009 at 4:57 PM, Dejan Muhamedagic > wrote: > > > > "conjoin" sounds sort of funny to me (as a non-native speaker). > > Equally so to me, and Australian is kinda like english. How about "coordinate"? Tim -- Tim Serong Senior Clustering Engineer, Novell Inc. ___ Pacemaker mailing list Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Re: [Pacemaker] RFC: Compacting constraints
On 2009-10-30T15:28:00, Dejan Muhamedagic wrote: > > > BTW, I guess that there are other CIB phrases which are commonly in > > > use. > > Right, but I think the "order A after B; collocation B with A" is likely > > the most common expression; we've got to start somewhere ;-) > Groups :) It's just that ms resources can't belong to a group. Groups aren't powerful enough for a variety of reasons. Resources can only be part of one group, for example. And ordering/collocating an unordered/uncollocated group with a clone also doesn't work. My educated guess is that this is because groups were meant to handle simple things, and abusing them for something complex doesn't work out well ;-) 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@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Re: [Pacemaker] RFC: Compacting constraints
Hi, On Fri, 30 Oct 2009 11:05 +0100, "Lars Marowsky-Bree" wrote: > On 2009-10-29T16:24:08, Dejan Muhamedagic wrote: > > > > There's a bunch of open issues (resource_sets not supporting score="0", > > > the crm shell not supporting resource_sets at all), > > That's on the todo list, I've even started working on it, but then had > > an issue with funny way resource sets are constructed in CIB. We had a > > discussion about that last year. > > Can you remind me/us please? Maybe we can fix some of the details still. > I admit I can't find the discussion from last year any more, > unfortunately. > > In particular the rsc_order support for resource sets doesn't just not > support score="", but also not the for/then action bits, which I think > might be extremely useful if I want to order several resources after a > master promotion; this also applies to collocation (and I also can't > collocate several resources with a node attribute). > > So I think the rsc sets still need a bit of fixing. That'd be great. I'll dig the discussion (should be somewhere) and produce a digest. > > There are no shell constructs which are rendered as two or more CIB > > elements. I guess that this should be possible, but really can't say > > until I take a thorough look at the implementation. > > That'd be cool. This would be much within the spirit of the CIB > representing atomic objects and management tools providing higher-level > abstraction. Agreed. > > BTW, I guess that there are other CIB phrases which are commonly in > > use. > > Right, but I think the "order A after B; collocation B with A" is likely > the most common expression; we've got to start somewhere ;-) Groups :) It's just that ms resources can't belong to a group. Thanks, Dejan > > 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@oss.clusterlabs.org > http://oss.clusterlabs.org/mailman/listinfo/pacemaker -- http://www.fastmail.fm - One of many happy users: http://www.fastmail.fm/docs/quotes.html ___ Pacemaker mailing list Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Re: [Pacemaker] RFC: Compacting constraints
On 2009-10-29T16:24:08, Dejan Muhamedagic wrote: > > There's a bunch of open issues (resource_sets not supporting score="0", > > the crm shell not supporting resource_sets at all), > That's on the todo list, I've even started working on it, but then had > an issue with funny way resource sets are constructed in CIB. We had a > discussion about that last year. Can you remind me/us please? Maybe we can fix some of the details still. I admit I can't find the discussion from last year any more, unfortunately. In particular the rsc_order support for resource sets doesn't just not support score="", but also not the for/then action bits, which I think might be extremely useful if I want to order several resources after a master promotion; this also applies to collocation (and I also can't collocate several resources with a node attribute). So I think the rsc sets still need a bit of fixing. > There are no shell constructs which are rendered as two or more CIB > elements. I guess that this should be possible, but really can't say > until I take a thorough look at the implementation. That'd be cool. This would be much within the spirit of the CIB representing atomic objects and management tools providing higher-level abstraction. > BTW, I guess that there are other CIB phrases which are commonly in > use. Right, but I think the "order A after B; collocation B with A" is likely the most common expression; we've got to start somewhere ;-) 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@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Re: [Pacemaker] RFC: Compacting constraints
Hi,
On Thu, 29 Oct 2009 14:39 +0100, "Lars Marowsky-Bree"
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
> colocation dummy10-c inf: base-clone dummy10
> colocation dummy11-c inf: base-clone dummy11
> colocation dummy12-c inf: base-clone dummy12
> colocation dummy13-c inf: base-clone dummy13
> colocation dummy14-c inf: base-clone dummy14
> colocation dummy15-c inf: base-clone dummy15
> colocation dummy16-c inf: base-clone dummy16
> colocation dummy17-c inf: base-clone dummy17
> colocation dummy18-c inf: base-clone dummy18
> colocation dummy19-c inf: base-clone dummy19
> colocation dummy2-c inf: base-clone dummy2
> colocation dummy3-c inf: base-clone dummy3
> colocation dummy4-c inf: base-clone dummy4
> colocation dummy5-c inf: base-clone dummy5
> colocation dummy6-c inf: base-clone dummy6
> colocation dummy7-c inf: base-clone dummy7
> colocation dummy8-c inf: base-clone dummy8
> colocation dummy9-c inf: base-clone dummy9
> order dummy1-o 0: base-clone dummy1
> order dummy10-o 0: base-clone dummy10
> order dummy11-o 0: base-clone dummy11
> order dummy12-o 0: base-clone dummy12
> order dummy13-o 0: base-clone dummy13
> order dummy14-o 0: base-clone dummy14
> order dummy15-o 0: base-clone dummy15
> order dummy16-o 0: base-clone dummy16
> order dummy17-o 0: base-clone dummy17
> order dummy18-o 0: base-clone dummy18
> order dummy19-o 0: base-clone dummy19
> order dummy2-o 0: base-clone dummy2
> order dummy3-o 0: base-clone dummy3
> order dummy4-o 0: base-clone dummy4
> order dummy5-o 0: base-clone dummy5
> order dummy6-o 0: base-clone dummy6
> order dummy7-o 0: base-clone dummy7
> order dummy8-o 0: base-clone dummy8
> order dummy9-o 0: base-clone dummy9
>
>
> There's a bunch of open issues (resource_sets not supporting score="0",
> the crm shell not supporting resource_sets at all),
That's on the todo list, I've even started working on it, but then had
an issue with funny way resource sets are constructed in CIB. We had a
discussion about that last year.
> 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? 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
There are no shell constructs which are rendered as two or more CIB
elements. I guess that this should be possible, but really can't say
until I take a thorough look at the implementation. BTW, I guess that
there are other CIB phrases which are commonly in use.
Thanks,
Dejan
> 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@oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
--
http://www.fastmail.fm - Send your email first class
___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
[Pacemaker] RFC: Compacting constraints
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
colocation dummy10-c inf: base-clone dummy10
colocation dummy11-c inf: base-clone dummy11
colocation dummy12-c inf: base-clone dummy12
colocation dummy13-c inf: base-clone dummy13
colocation dummy14-c inf: base-clone dummy14
colocation dummy15-c inf: base-clone dummy15
colocation dummy16-c inf: base-clone dummy16
colocation dummy17-c inf: base-clone dummy17
colocation dummy18-c inf: base-clone dummy18
colocation dummy19-c inf: base-clone dummy19
colocation dummy2-c inf: base-clone dummy2
colocation dummy3-c inf: base-clone dummy3
colocation dummy4-c inf: base-clone dummy4
colocation dummy5-c inf: base-clone dummy5
colocation dummy6-c inf: base-clone dummy6
colocation dummy7-c inf: base-clone dummy7
colocation dummy8-c inf: base-clone dummy8
colocation dummy9-c inf: base-clone dummy9
order dummy1-o 0: base-clone dummy1
order dummy10-o 0: base-clone dummy10
order dummy11-o 0: base-clone dummy11
order dummy12-o 0: base-clone dummy12
order dummy13-o 0: base-clone dummy13
order dummy14-o 0: base-clone dummy14
order dummy15-o 0: base-clone dummy15
order dummy16-o 0: base-clone dummy16
order dummy17-o 0: base-clone dummy17
order dummy18-o 0: base-clone dummy18
order dummy19-o 0: base-clone dummy19
order dummy2-o 0: base-clone dummy2
order dummy3-o 0: base-clone dummy3
order dummy4-o 0: base-clone dummy4
order dummy5-o 0: base-clone dummy5
order dummy6-o 0: base-clone dummy6
order dummy7-o 0: base-clone dummy7
order dummy8-o 0: base-clone dummy8
order dummy9-o 0: base-clone dummy9
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? 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@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
