<html>
<head>
</head>
<body style="margin-bottom: 1px; margin-top: 4px; font-size: 12pt; font-weight: normal; margin-right: 4px; line-height: normal; margin-left: 4px; font-variant: normal; font-style: normal; font-family: Lucida Grande">
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Lucida Grande">This would be useful to me. We have a similar monitoring infrastructure and have migration needs based upon node health. </font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Lucida Grande">-K </font><br><br><br>---<BR>Karl Katzke<BR>Systems Analyst II<BR>TAMU - DRGS<BR><BR><BR><BR><BR><br><br>>>> Andrew Beekhof <andrew@beekhof.net> 5/8/2009 6:26 AM >>><br>On Thu, May 7, 2009 at 10:24 PM, Mark Hamzy <hamzy@us.ibm.com> wrote:<br>> andrew@beekhof.net wrote on 05/07/2009 17:06:23 PM:<br>>> On Wed, May 6, 2009 at 11:32 PM, Mark Hamzy <hamzy@us.ibm.com> wrote:<br>>> ><br>><br>>> This is where the disconnect is.<br>>> You seem convinced that everyone will want to sum them up the same way<br>>> you do, for every resource in the cluster.<br>>> I'm not so sure.<br>><br>> Which is why I wrote the following:<br>><br>>> > How about a PE option for pacemaker to automatically calculate health?<br>>> > Admins could then enable these calculations if they do not want to go<br>>> > through the effort to investigate all of the health variables and how<br>>> > they might affect system operations?<br>><br>> Is putting code into pacemaker, so that system health is automatically<br>> calculated (when requested), something that the community wants?<br><br>Oh I don't doubt there is a non-trivial number of people want the<br>calculation done automatically.<br>Or even that many would want it calculated just as you describe.<br><br>My job though, is to also consider those for which the simplistic<br>model doesn't fit.<br>There must be a logical progression between the two usage styles.<br><br>Groups is a classic example of what happens when this isn't the case.<br>Everything you learnt about groups goes out the window once you have a<br>non-linear start order.<br><br>So what I think we need is the scores:<br>- node-health-score-red (defaults to -INFINITY),<br>- node-health-score-yellow (defaults to 0),<br>- node-health-score-green (defaults to 0),<br><br>These would work like the INFINITY an -INFINITY aliases (see char2score()).<br>So "red", "yellow" and "green" would be allowed anyway a score is<br>expected and used in the same way.<br>This could go into 1.0.x<br><br><br>Then I'd add<br>- node-base-score<br>Which cuts out half of the rsc_location constraints and seems like a<br>generically useful concept.<br>(One would probably look up this value and set node-weight during<br>unpack_nodes() )<br>I still debating whether this is suitable for 1.0<br><br><br>So now the constraints now look like:<br><br><rsc_location id="other_health" rsc="X"><br> <rule id="health_location_1" score-attribute="#health-ipmi"/><br> <rule id="health_location_2" score-attribute="#health-smart"/><br></rsc_location><br><br>Which one would only have to specify once for 1.2 when pattern<br>matching gets added (thats definitely not a change for a stable<br>series).<br><br>I don't consider this a huge configuration overhead, BUT, I wouldn't<br>object to adding<br>- node-health-strategy = (none, custom, migrate-on-red, ...)<br><br>* "none" would be the default<br>* "custom" would require the admin to configure the rsc_location<br>constraints manually<br>* "migrate-on-red" would be the one you're proposing and implicitly<br>create the relevant rsc_location constraints behind the scenes.<br> I'd not call it "automatic" in order to allow us to add other<br>"default" strategies in the future.<br><br>To me this seems like a good compromise between ease-of-use and<br>flexibility, with a sane progression from "none", to default<br>strategies, to "custom".<br><br>_______________________________________________<br>Pacemaker mailing list<br>Pacemaker@oss.clusterlabs.org<br><a href="http://oss.clusterlabs.org/mailman/listinfo/pacemaker">http://oss.clusterlabs.org/mailman/listinfo/pacemaker</a><br>
</p>
</body>
</html>