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