Re: [Pacemaker] [pacemaker][patch 3/4] Simple changes for Pacemaker Explained, Chapter 6 CH_Constraints.xml
On Fri, May 6, 2011 at 12:29 PM, Dejan Muhamedagic deja...@fastmail.fm wrote: On Fri, May 06, 2011 at 09:47:29AM +0200, Andrew Beekhof wrote: On Thu, May 5, 2011 at 5:20 PM, Dejan Muhamedagic deja...@fastmail.fm wrote: On Thu, May 05, 2011 at 12:02:01PM +0200, Andrew Beekhof wrote: On Thu, May 5, 2011 at 11:37 AM, Dejan Muhamedagic deja...@fastmail.fm wrote: On Thu, May 05, 2011 at 09:07:05AM +0200, Andrew Beekhof wrote: On Wed, May 4, 2011 at 7:15 PM, Dejan Muhamedagic deja...@fastmail.fm wrote: Hi, On Wed, May 04, 2011 at 12:49:03PM +0200, Andrew Beekhof wrote: Tick tock. I'm going to push this soon unless someone raises an objection RSN. On Fri, Apr 15, 2011 at 4:55 PM, Andrew Beekhof and...@beekhof.net wrote: On Fri, Apr 15, 2011 at 3:00 PM, Lars Marowsky-Bree l...@novell.com wrote: On 2011-04-13T08:37:12, Andrew Beekhof and...@beekhof.net wrote: Before: rsc_colocation id=coloc-set score=INFINITY resource_set id=coloc-set-0 resource_ref id=dummy2/ resource_ref id=dummy3/ /resource_set resource_set id=coloc-set-1 sequential=false role=Master resource_ref id=dummy0/ resource_ref id=dummy1/ /resource_set /rsc_colocation rsc_order id=order-set score=INFINITY resource_set id=order-set-0 role=Master resource_ref id=dummy0/ resource_ref id=dummy1/ /resource_set resource_set id=order-set-1 sequential=false resource_ref id=dummy2/ resource_ref id=dummy3/ /resource_set /rsc_order After: So I am understanding this properly - we're getting rid of the sequential attribute, yes? Absolutely. So, the internal-collocation replaces the sequential attribute? Yes. What are the possible and/or meaningfull values for internal-collocation? It looks like that would be 0 or INFINITY only, which would translate to old sequential false and true, right? No. choice data type=integer/ valueINFINITY/value value+INFINITY/value value-INFINITY/value /choice I saw that, but wonder what makes sense in this context. What's the difference between values 0, INF, 50, -50, 100? Are all those necessary? Just as necessary as for colocation constraints not involving sets. You're setting up the colocation score between elements of the set. OK. Looking at the schema, the ordering constraint lost score Score was being mapped to kind inside the PE anyway. and is using only the kind attribute which can have one of: valueNone/value valueOptional/value valueMandatory/value valueSerialize/value But then, the kind attribute is optional. If missing, how's that different from value None? If its missing you get the default. Which IIRC is Mandatory not None. What does Serialize mean? (in orders) Same as it did before, this is not new. What does score-attribute-mangle mean? (in collocations) As above. Not new. Where are these two documented? Couldn't find anything in the docs. Looks to be just an alias for XML_RULE_ATTR_SCORE_ATTRIBUTE dating back to 2005. So there is probably a reason I didn't document it. So, it's obsolete then? The crm shell actually never supported it :-| And I can't recall that I've ever seen it in a configuration. Serialize is newer. Its like optional but for a set - no member will start or stop at the same time as another. OK. I think that it'd be good to clarify the shell syntax before applying these changes. Actually I'm going to flip-flop here... there's really no need for this. Until the shell understands the new syntax, it will just show xml right? Right. But in my experience trying things out in shell syntax sometimes reveals design shortcomings. That was so with the resource sets. Going back to the example you've shown earlier in this thread ... Before: collocation c inf: ( dummy0:Master dummy1:Master ) dummy2 dummy3 order o Mandatory: dummy0:promote dummy1:promote ( dummy2 dummy3 ) After(1): collocation_set c inf: 0:[dummy0:Master dummy1:Master] inf:[dummy2 dummy3] order_set o Mandatory: Mandatory:[dummy0:promote dummy1:promote] Optional:[dummy2 dummy3] After(2): collocation_set c inf: 0:[dummy0:Master dummy1:Master] dummy2 dummy3 order_set o Mandatory: dummy0:promote dummy1:promote Optional:[dummy2 dummy3] The second version removes redundant specification, i.e. for the sets which have the same kind/score as the constraint. Would this kind
Re: [Pacemaker] [pacemaker][patch 3/4] Simple changes for Pacemaker Explained, Chapter 6 CH_Constraints.xml
On Thu, May 5, 2011 at 5:20 PM, Dejan Muhamedagic deja...@fastmail.fm wrote: On Thu, May 05, 2011 at 12:02:01PM +0200, Andrew Beekhof wrote: On Thu, May 5, 2011 at 11:37 AM, Dejan Muhamedagic deja...@fastmail.fm wrote: On Thu, May 05, 2011 at 09:07:05AM +0200, Andrew Beekhof wrote: On Wed, May 4, 2011 at 7:15 PM, Dejan Muhamedagic deja...@fastmail.fm wrote: Hi, On Wed, May 04, 2011 at 12:49:03PM +0200, Andrew Beekhof wrote: Tick tock. I'm going to push this soon unless someone raises an objection RSN. On Fri, Apr 15, 2011 at 4:55 PM, Andrew Beekhof and...@beekhof.net wrote: On Fri, Apr 15, 2011 at 3:00 PM, Lars Marowsky-Bree l...@novell.com wrote: On 2011-04-13T08:37:12, Andrew Beekhof and...@beekhof.net wrote: Before: rsc_colocation id=coloc-set score=INFINITY resource_set id=coloc-set-0 resource_ref id=dummy2/ resource_ref id=dummy3/ /resource_set resource_set id=coloc-set-1 sequential=false role=Master resource_ref id=dummy0/ resource_ref id=dummy1/ /resource_set /rsc_colocation rsc_order id=order-set score=INFINITY resource_set id=order-set-0 role=Master resource_ref id=dummy0/ resource_ref id=dummy1/ /resource_set resource_set id=order-set-1 sequential=false resource_ref id=dummy2/ resource_ref id=dummy3/ /resource_set /rsc_order After: So I am understanding this properly - we're getting rid of the sequential attribute, yes? Absolutely. So, the internal-collocation replaces the sequential attribute? Yes. What are the possible and/or meaningfull values for internal-collocation? It looks like that would be 0 or INFINITY only, which would translate to old sequential false and true, right? No. choice data type=integer/ valueINFINITY/value value+INFINITY/value value-INFINITY/value /choice I saw that, but wonder what makes sense in this context. What's the difference between values 0, INF, 50, -50, 100? Are all those necessary? Just as necessary as for colocation constraints not involving sets. You're setting up the colocation score between elements of the set. OK. Looking at the schema, the ordering constraint lost score Score was being mapped to kind inside the PE anyway. and is using only the kind attribute which can have one of: valueNone/value valueOptional/value valueMandatory/value valueSerialize/value But then, the kind attribute is optional. If missing, how's that different from value None? If its missing you get the default. Which IIRC is Mandatory not None. What does Serialize mean? (in orders) Same as it did before, this is not new. What does score-attribute-mangle mean? (in collocations) As above. Not new. Where are these two documented? Couldn't find anything in the docs. Looks to be just an alias for XML_RULE_ATTR_SCORE_ATTRIBUTE dating back to 2005. So there is probably a reason I didn't document it. So, it's obsolete then? The crm shell actually never supported it :-| And I can't recall that I've ever seen it in a configuration. Serialize is newer. Its like optional but for a set - no member will start or stop at the same time as another. OK. I think that it'd be good to clarify the shell syntax before applying these changes. Actually I'm going to flip-flop here... there's really no need for this. Until the shell understands the new syntax, it will just show xml right? Also, the changes wont be in a release until 1.1.7 and it will take a while to enter common usage. So I think you have time. I'm going to try to do something today and tomorrow, but next week I'll be away. So, if you're in a hurry, go ahead with the changes. Just two more notes regarding the language: There's colocation_set/internal-colocation and ordering_set/internal-ordering. They sound different. Should the order stuff be order_set/internal-order? I'm not partial to any and furthermore not a native speaker, so I'll leave that to you and others who are more intimate with english. As an engineer my grasp on english can be tenuous at times, but internal-order feels wrong. Are we going to name the new stuff differently in shell? Such as collocation_set and order(ing)_set? Though I don't like these in particular, because they are going to be the only ones with '_' in its names, I was using '-', but then I noticed all the other tag names used '_'. Then I remembered deciding at one point to use '_' for tag names (partly because changing them is hard) and '-' for attributes.
Re: [Pacemaker] [pacemaker][patch 3/4] Simple changes for Pacemaker Explained, Chapter 6 CH_Constraints.xml
On Fri, May 06, 2011 at 12:29:43PM +0200, Dejan Muhamedagic wrote: On Fri, May 06, 2011 at 09:47:29AM +0200, Andrew Beekhof wrote: On Thu, May 5, 2011 at 5:20 PM, Dejan Muhamedagic deja...@fastmail.fm wrote: On Thu, May 05, 2011 at 12:02:01PM +0200, Andrew Beekhof wrote: On Thu, May 5, 2011 at 11:37 AM, Dejan Muhamedagic deja...@fastmail.fm wrote: On Thu, May 05, 2011 at 09:07:05AM +0200, Andrew Beekhof wrote: On Wed, May 4, 2011 at 7:15 PM, Dejan Muhamedagic deja...@fastmail.fm wrote: Hi, On Wed, May 04, 2011 at 12:49:03PM +0200, Andrew Beekhof wrote: Tick tock. I'm going to push this soon unless someone raises an objection RSN. On Fri, Apr 15, 2011 at 4:55 PM, Andrew Beekhof and...@beekhof.net wrote: On Fri, Apr 15, 2011 at 3:00 PM, Lars Marowsky-Bree l...@novell.com wrote: On 2011-04-13T08:37:12, Andrew Beekhof and...@beekhof.net wrote: Before: rsc_colocation id=coloc-set score=INFINITY resource_set id=coloc-set-0 resource_ref id=dummy2/ resource_ref id=dummy3/ /resource_set resource_set id=coloc-set-1 sequential=false role=Master resource_ref id=dummy0/ resource_ref id=dummy1/ /resource_set /rsc_colocation rsc_order id=order-set score=INFINITY resource_set id=order-set-0 role=Master resource_ref id=dummy0/ resource_ref id=dummy1/ /resource_set resource_set id=order-set-1 sequential=false resource_ref id=dummy2/ resource_ref id=dummy3/ /resource_set /rsc_order After: So I am understanding this properly - we're getting rid of the sequential attribute, yes? Absolutely. So, the internal-collocation replaces the sequential attribute? Yes. What are the possible and/or meaningfull values for internal-collocation? It looks like that would be 0 or INFINITY only, which would translate to old sequential false and true, right? No. choice data type=integer/ valueINFINITY/value value+INFINITY/value value-INFINITY/value /choice I saw that, but wonder what makes sense in this context. What's the difference between values 0, INF, 50, -50, 100? Are all those necessary? Just as necessary as for colocation constraints not involving sets. You're setting up the colocation score between elements of the set. OK. Looking at the schema, the ordering constraint lost score Score was being mapped to kind inside the PE anyway. and is using only the kind attribute which can have one of: valueNone/value valueOptional/value valueMandatory/value valueSerialize/value But then, the kind attribute is optional. If missing, how's that different from value None? If its missing you get the default. Which IIRC is Mandatory not None. What does Serialize mean? (in orders) Same as it did before, this is not new. What does score-attribute-mangle mean? (in collocations) As above. Not new. Where are these two documented? Couldn't find anything in the docs. Looks to be just an alias for XML_RULE_ATTR_SCORE_ATTRIBUTE dating back to 2005. So there is probably a reason I didn't document it. So, it's obsolete then? The crm shell actually never supported it :-| And I can't recall that I've ever seen it in a configuration. Serialize is newer. Its like optional but for a set - no member will start or stop at the same time as another. OK. I think that it'd be good to clarify the shell syntax before applying these changes. Actually I'm going to flip-flop here... there's really no need for this. Until the shell understands the new syntax, it will just show xml right? Right. But in my experience trying things out in shell syntax sometimes reveals design shortcomings. That was so with the resource sets. Going back to the example you've shown earlier in this thread ... Before: collocation c inf: ( dummy0:Master dummy1:Master ) dummy2 dummy3 order o Mandatory: dummy0:promote dummy1:promote ( dummy2 dummy3 ) After(1): collocation_set c inf: 0:[dummy0:Master dummy1:Master] inf:[dummy2 dummy3] order_set o Mandatory: Mandatory:[dummy0:promote dummy1:promote] Optional:[dummy2 dummy3] After(2): collocation_set c inf: 0:[dummy0:Master dummy1:Master] dummy2 dummy3 order_set o Mandatory: dummy0:promote dummy1:promote Optional:[dummy2 dummy3] The second
Re: [Pacemaker] [pacemaker][patch 3/4] Simple changes for Pacemaker Explained, Chapter 6 CH_Constraints.xml
On Wed, May 4, 2011 at 6:25 PM, Tim Serong tser...@novell.com wrote: On 5/4/2011 at 08:49 PM, Andrew Beekhof and...@beekhof.net wrote: Tick tock. I'm going to push this soon unless someone raises an objection RSN. This is going into 1.1, right? Right (after going into devel first). I'm thinking its a 1.1.7 thing. Do existing CIBs automagically get updated to this syntax, or does the admin have to force this? (Sorry, I forget if that was covered already). We do non-persistent xslt upgrades inside of the PE. One needs to run cibadmin --upgrade to switch the rest of the system to the new syntax. ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [pacemaker][patch 3/4] Simple changes for Pacemaker Explained, Chapter 6 CH_Constraints.xml
On Thu, May 5, 2011 at 11:37 AM, Dejan Muhamedagic deja...@fastmail.fm wrote: On Thu, May 05, 2011 at 09:07:05AM +0200, Andrew Beekhof wrote: On Wed, May 4, 2011 at 7:15 PM, Dejan Muhamedagic deja...@fastmail.fm wrote: Hi, On Wed, May 04, 2011 at 12:49:03PM +0200, Andrew Beekhof wrote: Tick tock. I'm going to push this soon unless someone raises an objection RSN. On Fri, Apr 15, 2011 at 4:55 PM, Andrew Beekhof and...@beekhof.net wrote: On Fri, Apr 15, 2011 at 3:00 PM, Lars Marowsky-Bree l...@novell.com wrote: On 2011-04-13T08:37:12, Andrew Beekhof and...@beekhof.net wrote: Before: rsc_colocation id=coloc-set score=INFINITY resource_set id=coloc-set-0 resource_ref id=dummy2/ resource_ref id=dummy3/ /resource_set resource_set id=coloc-set-1 sequential=false role=Master resource_ref id=dummy0/ resource_ref id=dummy1/ /resource_set /rsc_colocation rsc_order id=order-set score=INFINITY resource_set id=order-set-0 role=Master resource_ref id=dummy0/ resource_ref id=dummy1/ /resource_set resource_set id=order-set-1 sequential=false resource_ref id=dummy2/ resource_ref id=dummy3/ /resource_set /rsc_order After: So I am understanding this properly - we're getting rid of the sequential attribute, yes? Absolutely. So, the internal-collocation replaces the sequential attribute? Yes. What are the possible and/or meaningfull values for internal-collocation? It looks like that would be 0 or INFINITY only, which would translate to old sequential false and true, right? No. choice data type=integer/ valueINFINITY/value value+INFINITY/value value-INFINITY/value /choice I saw that, but wonder what makes sense in this context. What's the difference between values 0, INF, 50, -50, 100? Are all those necessary? Just as necessary as for colocation constraints not involving sets. You're setting up the colocation score between elements of the set. Looking at the schema, the ordering constraint lost score Score was being mapped to kind inside the PE anyway. and is using only the kind attribute which can have one of: valueNone/value valueOptional/value valueMandatory/value valueSerialize/value But then, the kind attribute is optional. If missing, how's that different from value None? If its missing you get the default. Which IIRC is Mandatory not None. What does Serialize mean? (in orders) Same as it did before, this is not new. What does score-attribute-mangle mean? (in collocations) As above. Not new. Where are these two documented? Couldn't find anything in the docs. Looks to be just an alias for XML_RULE_ATTR_SCORE_ATTRIBUTE dating back to 2005. So there is probably a reason I didn't document it. Serialize is newer. Its like optional but for a set - no member will start or stop at the same time as another. It's good that finally the role/action got next to the resource. Agreed. I think that it'd be good to clarify the shell syntax before applying these changes. Yes, but I'm not going to wait forever. ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [pacemaker][patch 3/4] Simple changes for Pacemaker Explained, Chapter 6 CH_Constraints.xml
On Thu, May 05, 2011 at 12:02:01PM +0200, Andrew Beekhof wrote: On Thu, May 5, 2011 at 11:37 AM, Dejan Muhamedagic deja...@fastmail.fm wrote: On Thu, May 05, 2011 at 09:07:05AM +0200, Andrew Beekhof wrote: On Wed, May 4, 2011 at 7:15 PM, Dejan Muhamedagic deja...@fastmail.fm wrote: Hi, On Wed, May 04, 2011 at 12:49:03PM +0200, Andrew Beekhof wrote: Tick tock. I'm going to push this soon unless someone raises an objection RSN. On Fri, Apr 15, 2011 at 4:55 PM, Andrew Beekhof and...@beekhof.net wrote: On Fri, Apr 15, 2011 at 3:00 PM, Lars Marowsky-Bree l...@novell.com wrote: On 2011-04-13T08:37:12, Andrew Beekhof and...@beekhof.net wrote: Before: rsc_colocation id=coloc-set score=INFINITY resource_set id=coloc-set-0 resource_ref id=dummy2/ resource_ref id=dummy3/ /resource_set resource_set id=coloc-set-1 sequential=false role=Master resource_ref id=dummy0/ resource_ref id=dummy1/ /resource_set /rsc_colocation rsc_order id=order-set score=INFINITY resource_set id=order-set-0 role=Master resource_ref id=dummy0/ resource_ref id=dummy1/ /resource_set resource_set id=order-set-1 sequential=false resource_ref id=dummy2/ resource_ref id=dummy3/ /resource_set /rsc_order After: So I am understanding this properly - we're getting rid of the sequential attribute, yes? Absolutely. So, the internal-collocation replaces the sequential attribute? Yes. What are the possible and/or meaningfull values for internal-collocation? It looks like that would be 0 or INFINITY only, which would translate to old sequential false and true, right? No. choice data type=integer/ valueINFINITY/value value+INFINITY/value value-INFINITY/value /choice I saw that, but wonder what makes sense in this context. What's the difference between values 0, INF, 50, -50, 100? Are all those necessary? Just as necessary as for colocation constraints not involving sets. You're setting up the colocation score between elements of the set. OK. Looking at the schema, the ordering constraint lost score Score was being mapped to kind inside the PE anyway. and is using only the kind attribute which can have one of: valueNone/value valueOptional/value valueMandatory/value valueSerialize/value But then, the kind attribute is optional. If missing, how's that different from value None? If its missing you get the default. Which IIRC is Mandatory not None. What does Serialize mean? (in orders) Same as it did before, this is not new. What does score-attribute-mangle mean? (in collocations) As above. Not new. Where are these two documented? Couldn't find anything in the docs. Looks to be just an alias for XML_RULE_ATTR_SCORE_ATTRIBUTE dating back to 2005. So there is probably a reason I didn't document it. So, it's obsolete then? The crm shell actually never supported it :-| And I can't recall that I've ever seen it in a configuration. Serialize is newer. Its like optional but for a set - no member will start or stop at the same time as another. OK. I think that it'd be good to clarify the shell syntax before applying these changes. Yes, but I'm not going to wait forever. I'm going to try to do something today and tomorrow, but next week I'll be away. So, if you're in a hurry, go ahead with the changes. Just two more notes regarding the language: There's colocation_set/internal-colocation and ordering_set/internal-ordering. They sound different. Should the order stuff be order_set/internal-order? I'm not partial to any and furthermore not a native speaker, so I'll leave that to you and others who are more intimate with english. Are we going to name the new stuff differently in shell? Such as collocation_set and order(ing)_set? Though I don't like these in particular, because they are going to be the only ones with '_' in its names, but there seems to be no way around it. Any better suggestions? Thanks, Dejan ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [pacemaker][patch 3/4] Simple changes for Pacemaker Explained, Chapter 6 CH_Constraints.xml
Tick tock. I'm going to push this soon unless someone raises an objection RSN. On Fri, Apr 15, 2011 at 4:55 PM, Andrew Beekhof and...@beekhof.net wrote: On Fri, Apr 15, 2011 at 3:00 PM, Lars Marowsky-Bree l...@novell.com wrote: On 2011-04-13T08:37:12, Andrew Beekhof and...@beekhof.net wrote: Before: rsc_colocation id=coloc-set score=INFINITY resource_set id=coloc-set-0 resource_ref id=dummy2/ resource_ref id=dummy3/ /resource_set resource_set id=coloc-set-1 sequential=false role=Master resource_ref id=dummy0/ resource_ref id=dummy1/ /resource_set /rsc_colocation rsc_order id=order-set score=INFINITY resource_set id=order-set-0 role=Master resource_ref id=dummy0/ resource_ref id=dummy1/ /resource_set resource_set id=order-set-1 sequential=false resource_ref id=dummy2/ resource_ref id=dummy3/ /resource_set /rsc_order After: So I am understanding this properly - we're getting rid of the sequential attribute, yes? Absolutely. If so, three cheers. ;-) Can you share the proposed schema and XSLT, if you already have some? Attached rsc_colocation id=coloc-set score=INFINITY colocation_set id=coloc-set-1 internal-colocation=0 resource_ref id=dummy0 role=Master/ resource_ref id=dummy1 role=Master/ /colocation_set colocation_set id=coloc-set-0 internal-colocation=INFINITY resource_ref id=dummy2/ resource_ref id=dummy3/ /colocation_set /rsc_colocation rsc_order id=order-set kind=Mandatory ordering_set id=order-set-0 internal-ordering=Mandatory So we have (score|kind) on the outside, and internal-(ordering|colocation) on the inner elements. Is there a particular reason to use a different name on the inner ones? The language didn't feel right tbh - the inner ones felt like they needed more context/clarification. We can change the outer name too if you like. Also, rsc_order has either score or kind; are you doing away with that here? Yes. Standardizing on kind. Score never made sense for ordering :-( lifetime would only apply to the entire element, right? right And, just to be fully annoying - is there a real benefit to having ordering_set and colocation_set? Very much so. Because kind makes no sense for a colocation - and vice-versa for score. Using different element names means the rng can be stricter. ordering_set id=order-set-1 internal-ordering=Optional resource_ref id=dummy2/ While we're messing with sets anyway, I'd like to re-hash the idea I brought up on pcmk-devel. To make configuration more compact, I'd like to have automatic sets - i.e., the set of all resources that match something. Imagine: resource_list type=Xen provider=heartbeat class=ocf / and suddenly all your Xen guests are correctly ordered and collocated. The savings in administrative complexity and CIB size are huge. Or would you rather do this via templates? You mean something like? ordering_set id=order-set-0 internal-ordering=Mandatory resource_pattern type= provider= /ordering Might make sense. But doesn't strictly need to be bundled with this change. I'd be wary about allowing pattern matching on the name, I can imagine resources ending up in multiple sets (loops!) very easily. ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [pacemaker][patch 3/4] Simple changes for Pacemaker Explained, Chapter 6 CH_Constraints.xml
On 5/4/2011 at 08:49 PM, Andrew Beekhof and...@beekhof.net wrote: Tick tock. I'm going to push this soon unless someone raises an objection RSN. This is going into 1.1, right? Do existing CIBs automagically get updated to this syntax, or does the admin have to force this? (Sorry, I forget if that was covered already). Thanks, Tim On Fri, Apr 15, 2011 at 4:55 PM, Andrew Beekhof and...@beekhof.net wrote: On Fri, Apr 15, 2011 at 3:00 PM, Lars Marowsky-Bree l...@novell.com wrote: On 2011-04-13T08:37:12, Andrew Beekhof and...@beekhof.net wrote: Before: rsc_colocation id=coloc-set score=INFINITY resource_set id=coloc-set-0 resource_ref id=dummy2/ resource_ref id=dummy3/ /resource_set resource_set id=coloc-set-1 sequential=false role=Master resource_ref id=dummy0/ resource_ref id=dummy1/ /resource_set /rsc_colocation rsc_order id=order-set score=INFINITY resource_set id=order-set-0 role=Master resource_ref id=dummy0/ resource_ref id=dummy1/ /resource_set resource_set id=order-set-1 sequential=false resource_ref id=dummy2/ resource_ref id=dummy3/ /resource_set /rsc_order After: So I am understanding this properly - we're getting rid of the sequential attribute, yes? Absolutely. If so, three cheers. ;-) Can you share the proposed schema and XSLT, if you already have some? Attached rsc_colocation id=coloc-set score=INFINITY colocation_set id=coloc-set-1 internal-colocation=0 resource_ref id=dummy0 role=Master/ resource_ref id=dummy1 role=Master/ /colocation_set colocation_set id=coloc-set-0 internal-colocation=INFINITY resource_ref id=dummy2/ resource_ref id=dummy3/ /colocation_set /rsc_colocation rsc_order id=order-set kind=Mandatory ordering_set id=order-set-0 internal-ordering=Mandatory So we have (score|kind) on the outside, and internal-(ordering|colocation) on the inner elements. Is there a particular reason to use a different name on the inner ones? The language didn't feel right tbh - the inner ones felt like they needed more context/clarification. We can change the outer name too if you like. Also, rsc_order has either score or kind; are you doing away with that here? Yes. Standardizing on kind. Score never made sense for ordering :-( lifetime would only apply to the entire element, right? right And, just to be fully annoying - is there a real benefit to having ordering_set and colocation_set? Very much so. Because kind makes no sense for a colocation - and vice-versa for score. Using different element names means the rng can be stricter. ordering_set id=order-set-1 internal-ordering=Optional resource_ref id=dummy2/ While we're messing with sets anyway, I'd like to re-hash the idea I brought up on pcmk-devel. To make configuration more compact, I'd like to have automatic sets - i.e., the set of all resources that match something. Imagine: resource_list type=Xen provider=heartbeat class=ocf / and suddenly all your Xen guests are correctly ordered and collocated. The savings in administrative complexity and CIB size are huge. Or would you rather do this via templates? You mean something like? ordering_set id=order-set-0 internal-ordering=Mandatory resource_pattern type= provider= /ordering Might make sense. But doesn't strictly need to be bundled with this change. I'd be wary about allowing pattern matching on the name, I can imagine resources ending up in multiple sets (loops!) very easily. ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker -- Tim Serong tser...@novell.com Senior Clustering Engineer, OPS Engineering, Novell Inc. ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [pacemaker][patch 3/4] Simple changes for Pacemaker Explained, Chapter 6 CH_Constraints.xml
Hi, On Wed, May 04, 2011 at 12:49:03PM +0200, Andrew Beekhof wrote: Tick tock. I'm going to push this soon unless someone raises an objection RSN. On Fri, Apr 15, 2011 at 4:55 PM, Andrew Beekhof and...@beekhof.net wrote: On Fri, Apr 15, 2011 at 3:00 PM, Lars Marowsky-Bree l...@novell.com wrote: On 2011-04-13T08:37:12, Andrew Beekhof and...@beekhof.net wrote: Before: rsc_colocation id=coloc-set score=INFINITY resource_set id=coloc-set-0 resource_ref id=dummy2/ resource_ref id=dummy3/ /resource_set resource_set id=coloc-set-1 sequential=false role=Master resource_ref id=dummy0/ resource_ref id=dummy1/ /resource_set /rsc_colocation rsc_order id=order-set score=INFINITY resource_set id=order-set-0 role=Master resource_ref id=dummy0/ resource_ref id=dummy1/ /resource_set resource_set id=order-set-1 sequential=false resource_ref id=dummy2/ resource_ref id=dummy3/ /resource_set /rsc_order After: So I am understanding this properly - we're getting rid of the sequential attribute, yes? Absolutely. So, the internal-collocation replaces the sequential attribute? What are the possible and/or meaningfull values for internal-collocation? It looks like that would be 0 or INFINITY only, which would translate to old sequential false and true, right? Looking at the schema, the ordering constraint lost score and is using only the kind attribute which can have one of: valueNone/value valueOptional/value valueMandatory/value valueSerialize/value But then, the kind attribute is optional. If missing, how's that different from value None? What does Serialize mean? (in orders) What does score-attribute-mangle mean? (in collocations) It's good that finally the role/action got next to the resource. I think that it'd be good to clarify the shell syntax before applying these changes. Thanks, Dejan If so, three cheers. ;-) Can you share the proposed schema and XSLT, if you already have some? Attached rsc_colocation id=coloc-set score=INFINITY colocation_set id=coloc-set-1 internal-colocation=0 resource_ref id=dummy0 role=Master/ resource_ref id=dummy1 role=Master/ /colocation_set colocation_set id=coloc-set-0 internal-colocation=INFINITY resource_ref id=dummy2/ resource_ref id=dummy3/ /colocation_set /rsc_colocation rsc_order id=order-set kind=Mandatory ordering_set id=order-set-0 internal-ordering=Mandatory So we have (score|kind) on the outside, and internal-(ordering|colocation) on the inner elements. Is there a particular reason to use a different name on the inner ones? The language didn't feel right tbh - the inner ones felt like they needed more context/clarification. We can change the outer name too if you like. Also, rsc_order has either score or kind; are you doing away with that here? Yes. Standardizing on kind. Score never made sense for ordering :-( lifetime would only apply to the entire element, right? right And, just to be fully annoying - is there a real benefit to having ordering_set and colocation_set? Very much so. Because kind makes no sense for a colocation - and vice-versa for score. Using different element names means the rng can be stricter. ordering_set id=order-set-1 internal-ordering=Optional resource_ref id=dummy2/ While we're messing with sets anyway, I'd like to re-hash the idea I brought up on pcmk-devel. To make configuration more compact, I'd like to have automatic sets - i.e., the set of all resources that match something. Imagine: resource_list type=Xen provider=heartbeat class=ocf / and suddenly all your Xen guests are correctly ordered and collocated. The savings in administrative complexity and CIB size are huge. Or would you rather do this via templates? You mean something like? ordering_set id=order-set-0 internal-ordering=Mandatory resource_pattern type= provider= /ordering Might make sense. But doesn't strictly need to be bundled with this change. I'd be wary about allowing pattern matching on the name, I can imagine resources ending up in multiple sets (loops!) very easily. ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker ___ Pacemaker mailing
Re: [Pacemaker] [pacemaker][patch 3/4] Simple changes for Pacemaker Explained, Chapter 6 CH_Constraints.xml
On 2011-04-13T08:37:12, Andrew Beekhof and...@beekhof.net wrote: Before: rsc_colocation id=coloc-set score=INFINITY resource_set id=coloc-set-0 resource_ref id=dummy2/ resource_ref id=dummy3/ /resource_set resource_set id=coloc-set-1 sequential=false role=Master resource_ref id=dummy0/ resource_ref id=dummy1/ /resource_set /rsc_colocation rsc_order id=order-set score=INFINITY resource_set id=order-set-0 role=Master resource_ref id=dummy0/ resource_ref id=dummy1/ /resource_set resource_set id=order-set-1 sequential=false resource_ref id=dummy2/ resource_ref id=dummy3/ /resource_set /rsc_order After: So I am understanding this properly - we're getting rid of the sequential attribute, yes? If so, three cheers. ;-) Can you share the proposed schema and XSLT, if you already have some? rsc_colocation id=coloc-set score=INFINITY colocation_set id=coloc-set-1 internal-colocation=0 resource_ref id=dummy0 role=Master/ resource_ref id=dummy1 role=Master/ /colocation_set colocation_set id=coloc-set-0 internal-colocation=INFINITY resource_ref id=dummy2/ resource_ref id=dummy3/ /colocation_set /rsc_colocation rsc_order id=order-set kind=Mandatory ordering_set id=order-set-0 internal-ordering=Mandatory So we have (score|kind) on the outside, and internal-(ordering|colocation) on the inner elements. Is there a particular reason to use a different name on the inner ones? Also, rsc_order has either score or kind; are you doing away with that here? lifetime would only apply to the entire element, right? And, just to be fully annoying - is there a real benefit to having ordering_set and colocation_set? ordering_set id=order-set-1 internal-ordering=Optional resource_ref id=dummy2/ While we're messing with sets anyway, I'd like to re-hash the idea I brought up on pcmk-devel. To make configuration more compact, I'd like to have automatic sets - i.e., the set of all resources that match something. Imagine: resource_list type=Xen provider=heartbeat class=ocf / and suddenly all your Xen guests are correctly ordered and collocated. The savings in administrative complexity and CIB size are huge. Or would you rather do this via templates? 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 Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [pacemaker][patch 3/4] Simple changes for Pacemaker Explained, Chapter 6 CH_Constraints.xml
On Fri, Apr 15, 2011 at 3:00 PM, Lars Marowsky-Bree l...@novell.com wrote: On 2011-04-13T08:37:12, Andrew Beekhof and...@beekhof.net wrote: Before: rsc_colocation id=coloc-set score=INFINITY resource_set id=coloc-set-0 resource_ref id=dummy2/ resource_ref id=dummy3/ /resource_set resource_set id=coloc-set-1 sequential=false role=Master resource_ref id=dummy0/ resource_ref id=dummy1/ /resource_set /rsc_colocation rsc_order id=order-set score=INFINITY resource_set id=order-set-0 role=Master resource_ref id=dummy0/ resource_ref id=dummy1/ /resource_set resource_set id=order-set-1 sequential=false resource_ref id=dummy2/ resource_ref id=dummy3/ /resource_set /rsc_order After: So I am understanding this properly - we're getting rid of the sequential attribute, yes? Absolutely. If so, three cheers. ;-) Can you share the proposed schema and XSLT, if you already have some? Attached rsc_colocation id=coloc-set score=INFINITY colocation_set id=coloc-set-1 internal-colocation=0 resource_ref id=dummy0 role=Master/ resource_ref id=dummy1 role=Master/ /colocation_set colocation_set id=coloc-set-0 internal-colocation=INFINITY resource_ref id=dummy2/ resource_ref id=dummy3/ /colocation_set /rsc_colocation rsc_order id=order-set kind=Mandatory ordering_set id=order-set-0 internal-ordering=Mandatory So we have (score|kind) on the outside, and internal-(ordering|colocation) on the inner elements. Is there a particular reason to use a different name on the inner ones? The language didn't feel right tbh - the inner ones felt like they needed more context/clarification. We can change the outer name too if you like. Also, rsc_order has either score or kind; are you doing away with that here? Yes. Standardizing on kind. Score never made sense for ordering :-( lifetime would only apply to the entire element, right? right And, just to be fully annoying - is there a real benefit to having ordering_set and colocation_set? Very much so. Because kind makes no sense for a colocation - and vice-versa for score. Using different element names means the rng can be stricter. ordering_set id=order-set-1 internal-ordering=Optional resource_ref id=dummy2/ While we're messing with sets anyway, I'd like to re-hash the idea I brought up on pcmk-devel. To make configuration more compact, I'd like to have automatic sets - i.e., the set of all resources that match something. Imagine: resource_list type=Xen provider=heartbeat class=ocf / and suddenly all your Xen guests are correctly ordered and collocated. The savings in administrative complexity and CIB size are huge. Or would you rather do this via templates? You mean something like? ordering_set id=order-set-0 internal-ordering=Mandatory resource_pattern type= provider= /ordering Might make sense. But doesn't strictly need to be bundled with this change. I'd be wary about allowing pattern matching on the name, I can imagine resources ending up in multiple sets (loops!) very easily. constraints-1.1.rng Description: Binary data ?xml version=1.0 encoding=ISO-8859-1? xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:fn=http://www.w3.org/2005/02/xpath-functions; xsl:output method='xml' version='1.0' encoding='UTF-8' indent='yes'/ xsl:template match=rsc_order xsl:element name=rsc_order xsl:for-each select=@* xsl:choose xsl:when test=starts-with(name(), 'score') xsl:attribute name=kind xsl:choose xsl:when test=starts-with(., '0') xsl:textOptional/xsl:text /xsl:when xsl:otherwise xsl:textMandatory/xsl:text /xsl:otherwise /xsl:choose /xsl:attribute /xsl:when xsl:when test=starts-with(name(), 'role')/ xsl:otherwise xsl:apply-templates select=./ /xsl:otherwise /xsl:choose /xsl:for-each xsl:for-each select=resource_set xsl:element name=ordering_set xsl:apply-templates select=@id/ xsl:for-each select=../@kind xsl:attribute name=internal-orderingxsl:value-of select=../@kind//xsl:attribute /xsl:for-each xsl:for-each select=../@score xsl:attribute name=internal-ordering xsl:choose xsl:when test=starts-with(., '0') xsl:textNone/xsl:text /xsl:when xsl:otherwise xsl:textMandatory/xsl:text /xsl:otherwise /xsl:choose /xsl:attribute /xsl:for-each xsl:for-each select=@sequential xsl:attribute name=internal-ordering xsl:choose xsl:when test=starts-with(., '0') xsl:textNone/xsl:text /xsl:when xsl:when test=contains(., 'alse') xsl:textNone/xsl:text /xsl:when
Re: [Pacemaker] [pacemaker][patch 3/4] Simple changes for Pacemaker Explained, Chapter 6 CH_Constraints.xml
Here's an example of the before and after. Thoughts? Before: rsc_colocation id=coloc-set score=INFINITY resource_set id=coloc-set-0 resource_ref id=dummy2/ resource_ref id=dummy3/ /resource_set resource_set id=coloc-set-1 sequential=false role=Master resource_ref id=dummy0/ resource_ref id=dummy1/ /resource_set /rsc_colocation rsc_order id=order-set score=INFINITY resource_set id=order-set-0 role=Master resource_ref id=dummy0/ resource_ref id=dummy1/ /resource_set resource_set id=order-set-1 sequential=false resource_ref id=dummy2/ resource_ref id=dummy3/ /resource_set /rsc_order After: rsc_colocation id=coloc-set score=INFINITY colocation_set id=coloc-set-1 internal-colocation=0 resource_ref id=dummy0 role=Master/ resource_ref id=dummy1 role=Master/ /colocation_set colocation_set id=coloc-set-0 internal-colocation=INFINITY resource_ref id=dummy2/ resource_ref id=dummy3/ /colocation_set /rsc_colocation rsc_order id=order-set kind=Mandatory ordering_set id=order-set-0 internal-ordering=Mandatory resource_ref id=dummy0 role=Master/ resource_ref id=dummy1 role=Master/ /ordering_set ordering_set id=order-set-1 internal-ordering=Optional resource_ref id=dummy2/ resource_ref id=dummy3/ /ordering_set /rsc_order On Mon, Apr 11, 2011 at 6:02 PM, Andrew Beekhof and...@beekhof.net wrote: On Mon, Apr 11, 2011 at 3:41 PM, Andrew Beekhof and...@beekhof.net wrote: On Mon, Apr 11, 2011 at 2:33 PM, Tim Serong tser...@novell.com wrote: For members within a set (sequential=true), it is true that for a given member to be active, the previous members must also be active. Between sets however, it's the other way around - a given set depends on the subsequent set. Did I really write it like that? You tested it? Yup. Well, I tested it (pcmk 1.1.5), so I assume you wrote it like that :) We want (pardon the ASCII art): /-- C --\ G -- F --+--- D ---+-- B -- A \- - E --/ Test is: # crm configure colocation c inf: F G ( C D E ) A B Given the well discussed issues with the shell syntax, I'd prefer to see the raw xml actually. constraints rsc_colocation id=c score=INFINITY resource_set id=c-0 resource_ref id=F/ resource_ref id=G/ /resource_set resource_set id=c-1 sequential=false resource_ref id=C/ resource_ref id=D/ resource_ref id=E/ /resource_set resource_set id=c-2 resource_ref id=A/ resource_ref id=B/ /resource_set /rsc_colocation /constraints So, at least for colocation, s/at least// I double checked ordering constraints and they work as I think they should. The basic equivalent to c-2 would be first=A then=B which I believe makes sense. And if the sets were collapsed, the equivalent is first=c-0 then=c-1, first=c-1 then=c-2 which is again the ordering you'd get from a group. So it looks like we just need to fix the order in which colocation sets are processed. I already know how to use xslt for the conversion, we just need to finalize the syntax. it looks like we want either the order within the set to be the reverse of what it is now. Ie. resource_set id=c-2 resource_ref id=B/ resource_ref id=A/ /resource_set Or the order of the sets reversed (so as to work like groups). On further reflection, I'm pretty sure this is what we want (and what I had intended originally). Ie. resource_set id=c-2 resource_ref id=A/ resource_ref id=B/ /resource_set resource_set id=c-1 sequential=false resource_ref id=C/ resource_ref id=D/ resource_ref id=E/ /resource_set resource_set id=c-0 resource_ref id=F/ resource_ref id=G/ /resource_set Which do people think is going to be more comprehendible? Since we want new behavior, we should use a new syntax to be able to distinguish between the two. Which is handy because the existing syntax is clearly challenging. At a minimum we want s/resource_set/colocation_set/g Two additional open questions, How to indicate the scores: - between the sets Keep using the score from the constraint? - between resources within a set (sequential is clearly too confusing). Perhaps with internal_score and external_score attributes for colocation_set's. Where the value of external_score on colocation_set N reflects the colocation preference with set N-1 (ie. the one above it in xml syntax). And also: - how to deal with roles and instances sanely?
Re: [Pacemaker] [pacemaker][patch 3/4] Simple changes for Pacemaker Explained, Chapter 6 CH_Constraints.xml
On 3/21/2011 at 08:20 PM, Andrew Beekhof and...@beekhof.net wrote: Small improvement to: + The only thing that matters is that in order for any member of a set to be active, all the members of the previous set must also be active (and naturally on the same node). When a set has literalsequential=true/literal, then in order for any member to be active, the previous members must also be active. + The only thing that matters is that in order for any member of a set to be active, all the members of the previous setfootnoteparaas determined by the display order in the configuration/para/footnote must also be active (and naturally on the same node). + When a set has literalsequential=true/literal, then in order for any member to be active, the previous members must also be active. This isn't quite correct. For members within a set (sequential=true), it is true that for a given member to be active, the previous members must also be active. Between sets however, it's the other way around - a given set depends on the subsequent set. The example colocation chain in Pacemaker Explained right now should thus be changed as follows in order to match the diagram: constraints rsc_colocation id=coloc-1 score=INFINITY resource_set id=collocated-set-1 sequential=true -resource_ref id=A/ -resource_ref id=B/ +resource_ref id=F/ +resource_ref id=G/ /resource_set resource_set id=collocated-set-2 sequential=false resource_ref id=C/ resource_ref id=D/ resource_ref id=E/ /resource_set resource_set id=collocated-set-2 sequential=true role=Master -resource_ref id=F/ -resource_ref id=G/ +resource_ref id=A/ +resource_ref id=B/ /resource_set /rsc_colocation /constraints Regards, Tim -- Tim Serong tser...@novell.com Senior Clustering Engineer, OPS Engineering, Novell Inc. ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [pacemaker][patch 3/4] Simple changes for Pacemaker Explained, Chapter 6 CH_Constraints.xml
On Mon, Apr 11, 2011 at 12:57 PM, Tim Serong tser...@novell.com wrote: On 3/21/2011 at 08:20 PM, Andrew Beekhof and...@beekhof.net wrote: Small improvement to: + The only thing that matters is that in order for any member of a set to be active, all the members of the previous set must also be active (and naturally on the same node). When a set has literalsequential=true/literal, then in order for any member to be active, the previous members must also be active. + The only thing that matters is that in order for any member of a set to be active, all the members of the previous setfootnoteparaas determined by the display order in the configuration/para/footnote must also be active (and naturally on the same node). + When a set has literalsequential=true/literal, then in order for any member to be active, the previous members must also be active. This isn't quite correct. For members within a set (sequential=true), it is true that for a given member to be active, the previous members must also be active. Between sets however, it's the other way around - a given set depends on the subsequent set. Did I really write it like that? You tested it? If so, thats just retarded and needs an overhaul. The example colocation chain in Pacemaker Explained right now should thus be changed as follows in order to match the diagram: constraints rsc_colocation id=coloc-1 score=INFINITY resource_set id=collocated-set-1 sequential=true - resource_ref id=A/ - resource_ref id=B/ + resource_ref id=F/ + resource_ref id=G/ /resource_set resource_set id=collocated-set-2 sequential=false resource_ref id=C/ resource_ref id=D/ resource_ref id=E/ /resource_set resource_set id=collocated-set-2 sequential=true role=Master - resource_ref id=F/ - resource_ref id=G/ + resource_ref id=A/ + resource_ref id=B/ /resource_set /rsc_colocation /constraints Regards, Tim -- Tim Serong tser...@novell.com Senior Clustering Engineer, OPS Engineering, Novell Inc. ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [pacemaker][patch 3/4] Simple changes for Pacemaker Explained, Chapter 6 CH_Constraints.xml
On 4/11/2011 at 09:37 PM, Andrew Beekhof and...@beekhof.net wrote: On Mon, Apr 11, 2011 at 12:57 PM, Tim Serong tser...@novell.com wrote: On 3/21/2011 at 08:20 PM, Andrew Beekhof and...@beekhof.net wrote: Small improvement to: + The only thing that matters is that in order for any member of a set to be active, all the members of the previous set must also be active (and naturally on the same node). When a set has literalsequential=true/literal, then in order for any member to be active, the previous members must also be active. + The only thing that matters is that in order for any member of a set to be active, all the members of the previous setfootnoteparaas determined by the display order in the configuration/para/footnote must also be active (and naturally on the same node). + When a set has literalsequential=true/literal, then in order for any member to be active, the previous members must also be active. This isn't quite correct. For members within a set (sequential=true), it is true that for a given member to be active, the previous members must also be active. Between sets however, it's the other way around - a given set depends on the subsequent set. Did I really write it like that? You tested it? Yup. Well, I tested it (pcmk 1.1.5), so I assume you wrote it like that :) We want (pardon the ASCII art): /-- C --\ G -- F --+--- D ---+-- B -- A \-- E --/ Test is: # crm configure colocation c inf: F G ( C D E ) A B # crm resource stop F (stops F and G) # crm resource start F # crm resource stop D (stops D, F and G) # crm resource start D # crm resource stop B (stops everything except A) That shell colocation constraint maps exactly to the (new) XML shown below (verified just in case it turned out to be a shell oddity). If so, thats just retarded and needs an overhaul. It is a little... confusing. Regards, Tim The example colocation chain in Pacemaker Explained right now should thus be changed as follows in order to match the diagram: constraints rsc_colocation id=coloc-1 score=INFINITY resource_set id=collocated-set-1 sequential=true -resource_ref id=A/ -resource_ref id=B/ +resource_ref id=F/ +resource_ref id=G/ /resource_set resource_set id=collocated-set-2 sequential=false resource_ref id=C/ resource_ref id=D/ resource_ref id=E/ /resource_set resource_set id=collocated-set-2 sequential=true role=Master -resource_ref id=F/ -resource_ref id=G/ +resource_ref id=A/ +resource_ref id=B/ /resource_set /rsc_colocation /constraints Regards, Tim -- Tim Serong tser...@novell.com Senior Clustering Engineer, OPS Engineering, Novell Inc. ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker -- Tim Serong tser...@novell.com Senior Clustering Engineer, OPS Engineering, Novell Inc. ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [pacemaker][patch 3/4] Simple changes for Pacemaker Explained, Chapter 6 CH_Constraints.xml
On Mon, Apr 11, 2011 at 2:18 PM, Tim Serong tser...@novell.com wrote: On 4/11/2011 at 09:37 PM, Andrew Beekhof and...@beekhof.net wrote: On Mon, Apr 11, 2011 at 12:57 PM, Tim Serong tser...@novell.com wrote: On 3/21/2011 at 08:20 PM, Andrew Beekhof and...@beekhof.net wrote: Small improvement to: + The only thing that matters is that in order for any member of a set to be active, all the members of the previous set must also be active (and naturally on the same node). When a set has literalsequential=true/literal, then in order for any member to be active, the previous members must also be active. + The only thing that matters is that in order for any member of a set to be active, all the members of the previous setfootnoteparaas determined by the display order in the configuration/para/footnote must also be active (and naturally on the same node). + When a set has literalsequential=true/literal, then in order for any member to be active, the previous members must also be active. This isn't quite correct. For members within a set (sequential=true), it is true that for a given member to be active, the previous members must also be active. Between sets however, it's the other way around - a given set depends on the subsequent set. Did I really write it like that? You tested it? Yup. Well, I tested it (pcmk 1.1.5), so I assume you wrote it like that :) We want (pardon the ASCII art): /-- C --\ G -- F --+--- D ---+-- B -- A \-- E --/ Test is: # crm configure colocation c inf: F G ( C D E ) A B Given the well discussed issues with the shell syntax, I'd prefer to see the raw xml actually. # crm resource stop F (stops F and G) # crm resource start F # crm resource stop D (stops D, F and G) # crm resource start D # crm resource stop B (stops everything except A) That shell colocation constraint maps exactly to the (new) XML shown below (verified just in case it turned out to be a shell oddity). If so, thats just retarded and needs an overhaul. It is a little... confusing. Regards, Tim The example colocation chain in Pacemaker Explained right now should thus be changed as follows in order to match the diagram: constraints rsc_colocation id=coloc-1 score=INFINITY resource_set id=collocated-set-1 sequential=true - resource_ref id=A/ - resource_ref id=B/ + resource_ref id=F/ + resource_ref id=G/ /resource_set resource_set id=collocated-set-2 sequential=false resource_ref id=C/ resource_ref id=D/ resource_ref id=E/ /resource_set resource_set id=collocated-set-2 sequential=true role=Master - resource_ref id=F/ - resource_ref id=G/ + resource_ref id=A/ + resource_ref id=B/ /resource_set /rsc_colocation /constraints Regards, Tim -- Tim Serong tser...@novell.com Senior Clustering Engineer, OPS Engineering, Novell Inc. ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker -- Tim Serong tser...@novell.com Senior Clustering Engineer, OPS Engineering, Novell Inc. ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [pacemaker][patch 3/4] Simple changes for Pacemaker Explained, Chapter 6 CH_Constraints.xml
On 4/11/2011 at 10:23 PM, Andrew Beekhof and...@beekhof.net wrote: On Mon, Apr 11, 2011 at 2:18 PM, Tim Serong tser...@novell.com wrote: On 4/11/2011 at 09:37 PM, Andrew Beekhof and...@beekhof.net wrote: On Mon, Apr 11, 2011 at 12:57 PM, Tim Serong tser...@novell.com wrote: On 3/21/2011 at 08:20 PM, Andrew Beekhof and...@beekhof.net wrote: Small improvement to: + The only thing that matters is that in order for any member of a set to be active, all the members of the previous set must also be active (and naturally on the same node). When a set has literalsequential=true/literal, then in order for any member to be active, the previous members must also be active. + The only thing that matters is that in order for any member of a set to be active, all the members of the previous setfootnoteparaas determined by the display order in the configuration/para/footnote must also be active (and naturally on the same node). + When a set has literalsequential=true/literal, then in order for any member to be active, the previous members must also be active. This isn't quite correct. For members within a set (sequential=true), it is true that for a given member to be active, the previous members must also be active. Between sets however, it's the other way around - a given set depends on the subsequent set. Did I really write it like that? You tested it? Yup. Well, I tested it (pcmk 1.1.5), so I assume you wrote it like that :) We want (pardon the ASCII art): /-- C --\ G -- F --+--- D ---+-- B -- A \- - E --/ Test is: # crm configure colocation c inf: F G ( C D E ) A B Given the well discussed issues with the shell syntax, I'd prefer to see the raw xml actually. constraints rsc_colocation id=c score=INFINITY resource_set id=c-0 resource_ref id=F/ resource_ref id=G/ /resource_set resource_set id=c-1 sequential=false resource_ref id=C/ resource_ref id=D/ resource_ref id=E/ /resource_set resource_set id=c-2 resource_ref id=A/ resource_ref id=B/ /resource_set /rsc_colocation /constraints # crm resource stop F (stops F and G) # crm resource start F # crm resource stop D (stops D, F and G) # crm resource start D # crm resource stop B (stops everything except A) That shell colocation constraint maps exactly to the (new) XML shown below (verified just in case it turned out to be a shell oddity). If so, thats just retarded and needs an overhaul. It is a little... confusing. Regards, Tim The example colocation chain in Pacemaker Explained right now should thus be changed as follows in order to match the diagram: constraints rsc_colocation id=coloc-1 score=INFINITY resource_set id=collocated-set-1 sequential=true -resource_ref id=A/ -resource_ref id=B/ +resource_ref id=F/ +resource_ref id=G/ /resource_set resource_set id=collocated-set-2 sequential=false resource_ref id=C/ resource_ref id=D/ resource_ref id=E/ /resource_set resource_set id=collocated-set-2 sequential=true role=Master -resource_ref id=F/ -resource_ref id=G/ +resource_ref id=A/ +resource_ref id=B/ /resource_set /rsc_colocation /constraints Regards, Tim -- Tim Serong tser...@novell.com Senior Clustering Engineer, OPS Engineering, Novell Inc. ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker -- Tim Serong tser...@novell.com Senior Clustering Engineer, OPS Engineering, Novell Inc. ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker -- Tim Serong tser...@novell.com Senior Clustering Engineer, OPS Engineering, Novell Inc. ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home:
Re: [Pacemaker] [pacemaker][patch 3/4] Simple changes for Pacemaker Explained, Chapter 6 CH_Constraints.xml
Needs some updates. + Scores of all kinds are integral to how a cluster works. well, not all clusters, just pacemaker ones. How about: + Scores of all kinds are integral to how Pacemaker clusters work. Assume the intent was to avoid confusion with actual sets here? - titleExample set of opt-in location constraints/title + titleExample of opt-in location constraints/title Prefer something like: + titleExample usage of opt-in location constraints/title or similar to indicate that they only make sense together. I usually try to avoid questions as titles: - titleWhat if Two Nodes Have the Same Score/title + titleWhat if Two Nodes Have the Same Score?/title How about: + titleWhen Two Nodes Have the Same Score/title I like the existing text in this case - titleSpecifying the Order Resources Should Start/Stop In/title - paraThe way to specify the order in which resources should start is by creating literalrsc_order/literal constraints./para + titleSpecifying Resource Start/Stop Order/title + paraUse a literalrsc_order/literal constraint to specify resource ordering./para Also here: - entryThe name of a resource that must be started before the then resource is allowed to. /entry + entryThe name of a resource that must be started before the then resource. /entry Although changing to be a literal would be an improvement. Also think colocation makes more sense than resource here: - entryThe colocation target. The cluster will decide where to put this resource first and then decide where to put the resource in the rsc field/entry + entryThe resource target. The cluster will decide where to put this resource first and then decide where to put the colocation resource specified in the rsc field/entry + paraResource sets were introduced for ordering and dependency contraints to simplify this situation./para Prefer instead: + paraTo simplify the construction of ordering chains, the resource set syntax may be used instead./para +Using resource sets for complex colocation contraints makes things easier. Prefer: + paraTo simplify the construction of colocation chains, the resource set syntax may be used instead./para nack, the word equivalent is important here - titleThe equivalent colocation chain expressed using resource_sets/title + titleA resource set for the same colocation dependency chain/title and here: - titleA group resource with the equivalent colocation rules/title + titleA group resource for the same colocation dependency chain/title Small improvement to: + The only thing that matters is that in order for any member of a set to be active, all the members of the previous set must also be active (and naturally on the same node). When a set has literalsequential=true/literal, then in order for any member to be active, the previous members must also be active. + The only thing that matters is that in order for any member of a set to be active, all the members of the previous setfootnoteparaas determined by the display order in the configuration/para/footnote must also be active (and naturally on the same node). + When a set has literalsequential=true/literal, then in order for any member to be active, the previous members must also be active. Strictly speaking, they do have ordering dependancies, just not within the set. + captionVisual representation of a colocation chain where the members of the middle set have no order dependencies/caption Suggest: + captionVisual representation of a colocation chain where the members of the middle set have no ordering dependencies with the other sets/caption On Mon, Mar 21, 2011 at 3:51 AM, Marcus Barrow mbar...@redhat.com wrote: More simple changes for the Pacemaker Explained document. These are for CH_Constraints.xml and consist of typos and small changes. It also includes a change to Section 6.6 where dependency on preceding sets and preceding members of sets are described as M=1 and N+1. These were just changed to use the word preceding, which might be more clear. Regards, Marcus Barrow ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
[Pacemaker] [pacemaker][patch 3/4] Simple changes for Pacemaker Explained, Chapter 6 CH_Constraints.xml
More simple changes for the Pacemaker Explained document. These are for CH_Constraints.xml and consist of typos and small changes. It also includes a change to Section 6.6 where dependency on preceding sets and preceding members of sets are described as M=1 and N+1. These were just changed to use the word preceding, which might be more clear. Regards, Marcus Barrow CH-Constraints.xml.1stpatch Description: Binary data ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
