<html><body>
<p>andrew@beekhof.net wrote on 05/08/2009 13:26:16 PM:<br>
> On Thu, May 7, 2009 at 10:24 PM, Mark Hamzy <hamzy@us.ibm.com> wrote:<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>
Agreed.<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>
Could you explain more here (and give an example), please? I am<br>
new to HA and feel that I must be missing something.<br>
<br>
All nodes start at zero unless some rule is defined to give them<br>
a weight. Are you proposing that they would start at some<br>
user-defined value? For example, 100?<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>
Yes. "migrate-on-red" would automatically all variables that start<br>
with #health. This would reduce the chance of errors in forgetting<br>
a variable, adding a new monitored variable later on, or mispelling<br>
a variable.<br>
<br>
What is the difference between "none" and "custom"?<br>
<br>
I image that a sysadmin could set "none" and still define only<br>
the #health variables that they are interested in the other_health<br>
rsc_location list.<br>
<br>
This would work the same as "custom". I imagine that you mean<br>
"custom" to possibly inform HA that these rules exist and are<br>
being used as intended (not to be defaulted in anyway).<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>
Yes.<br>
<br>
Mark</body></html>