<html><body>
<p><tt><font size="2">beekhof@gmail.com wrote on 04/24/2009 11:00:01 AM:<br>
&gt;<br>
&gt; On Thu, Apr 23, 2009 at 17:49, Mark Hamzy &lt;hamzy@us.ibm.com&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; Health Attribute-value Meaning<br>
&gt; &gt; green 1000 server is happy, capable of running any resource<br>
&gt; &gt; yellow 0 server is marginal - it is desirable to schedule resources<br>
&gt; &gt; somewhere else if you can<br>
&gt; &gt; red -INFINITY server is unreliable (but still up) and should not be used<br>
&gt; &gt;<br>
&gt; &gt; Note that all of the values given would be configuration-specific. These<br>
&gt; &gt; attributes would be set via attrd_updater.<br>
&gt;<br>
&gt; Agreed.<br>
&gt; What I'm not yet clear on though, is why you can't just use these<br>
&gt; attribute with the existing rsc_location constraints.<br>
&gt;<br>
&gt; (And even if there is a need to expose it differently to users, it<br>
&gt; should definitely be using the rsc_location logic internally)<br>
<br>
A machine now has three states as it is a part of a cluster. &nbsp;When some<br>
process detects that a failure is imminent, we want to notify the manager<br>
to move resources off of that node.<br>
<br>
If daemons asynchronously update variables with values, then system administrators<br>
need to modify their setups with each known #health-x variable. &nbsp;Each of the M<br>
constraints needs N variables as input to the overall calculations.<br>
<br>
For example, this simple constraint:<br>
<br>
&lt;constraints&gt;<br>
 &nbsp;&lt;rsc_location id=&quot;rsc_location_apache_1&quot; rsc=&quot;apache_1&quot;&gt;<br>
 &nbsp; &nbsp;&lt;rule id=&quot;prefered_location_apache_1&quot; score=&quot;100&quot;&gt;<br>
 &nbsp; &nbsp; &nbsp;&lt;expression attribute=&quot;#uname&quot; id=&quot;prefered_location_apache_1_expr&quot; operation=&quot;eq&quot; value=&quot;hs21c&quot;/&gt;<br>
 &nbsp; &nbsp;&lt;/rule&gt;<br>
 &nbsp;&lt;/rsc_location&gt;<br>
&lt;/constraints&gt;<br>
<br>
becomes:<br>
<br>
&lt;constraints&gt;<br>
 &nbsp;&lt;rsc_location id=&quot;rsc_location_apache_1&quot; rsc=&quot;apache_1&quot;&gt;<br>
 &nbsp; &nbsp;&lt;rule id=&quot;prefered_location_apache_1&quot; score=&quot;100&quot;&gt;<br>
 &nbsp; &nbsp; &nbsp;&lt;expression attribute=&quot;#uname&quot; id=&quot;apache_1_uname_expr&quot; operation=&quot;eq&quot; value=&quot;hs21c&quot;/&gt;<br>
 &nbsp; &nbsp;&lt;/rule&gt;<br>
 &nbsp;&lt;/rsc_location&gt;<br>
 &nbsp;&lt;rsc_location id=&quot;rsc_location_apache_2&quot; rsc=&quot;apache_1&quot;&gt;<br>
 &nbsp; &nbsp;&lt;rule id=&quot;health_location_1_apache_1&quot; score_attribute=&quot;#health-ipmi&quot;&gt;<br>
 &nbsp; &nbsp; &nbsp;&lt;expression attribute=&quot;#health-ipmi&quot; id=&quot;apache_1_ipmi_expr&quot; operation=&quot;defined&quot;/&gt;<br>
 &nbsp; &nbsp;&lt;/rule&gt;<br>
 &nbsp;&lt;/rsc_location&gt;<br>
 &nbsp;&lt;rsc_location id=&quot;rsc_location_apache_3&quot; rsc=&quot;apache_1&quot;&gt;<br>
 &nbsp; &nbsp;&lt;rule id=&quot;health_location_2_apache_1&quot; score-attribute=&quot;#health-smart&quot;&gt;<br>
 &nbsp; &nbsp; &nbsp;&lt;expression attribute=&quot;#health-smart&quot; id=&quot;apache_1_smart_expr&quot; operation=&quot;defined&quot;/&gt;<br>
 &nbsp; &nbsp;&lt;/rule&gt;<br>
 &nbsp;&lt;/rsc_location&gt;<br>
&lt;/constraints&gt;<br>
<br>
Not only does this has to be done for all of the resources, but new health metrics must<br>
be known to the administrators.<br>
<br>
This is a logistical nightmare. &nbsp;What I am proposing is that pacemaker add health<br>
scores to nodes. &nbsp;Currently, nodes with no rules applied to them start at zero.<br>
<br>
We want the constraints left alone.<br>
<br>
&lt;constraints&gt;<br>
 &nbsp;&lt;rsc_location id=&quot;rsc_location_apache_1&quot; rsc=&quot;apache_1&quot;&gt;<br>
 &nbsp; &nbsp;&lt;rule id=&quot;prefered_location_apache_1&quot; score=&quot;100&quot;&gt;<br>
 &nbsp; &nbsp; &nbsp;&lt;expression attribute=&quot;#uname&quot; id=&quot;prefered_location_apache_1_expr&quot; operation=&quot;eq&quot; value=&quot;hs21c&quot;/&gt;<br>
 &nbsp; &nbsp;&lt;/rule&gt;<br>
 &nbsp;&lt;/rsc_location&gt;<br>
&lt;/constraints&gt;<br>
<br>
How were you proposing that this should be done under the current rsc_location?<br>
<br>
&gt; &gt; There should be an API for health monitoring agents.<br>
&gt;<br>
&gt; More information?<br>
&gt;<br>
&gt; &gt; This would be similar to cluster-wide default set by symmetric-cluster true<br>
&gt; &gt; (0) or false (-INFINITY).<br>
&gt;<br>
&gt; You lost me here.<br>
<br>
When I moved the conversation here, I incorporated two of the comments from the other<br>
mailing list. &nbsp;The full comments were as follows:<br>
<br>
misch@multinet.de wrote:<br>
&gt; There also should be a clean documented API to write you own health-... agents <br>
&gt; monitoring the system itself.<br>
<br>
lmb@suse.de wrote:<br>
&gt; Basically your mechanism modifies the &quot;base score&quot; for a node, somewhat<br>
&gt; similar to the cluster-wide default set by symmetric-cluster true (0) or<br>
&gt; false (-INFINITY).<br>
&gt;<br>
&gt; Sure, but I'd go even beyond this and just add the mechanism for setting<br>
&gt; the base score; translating health scores into these can be done outside<br>
&gt; the core system.<br>
</font></tt><br>
<tt><font size="2">Mark</font></tt></body></html>