<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&nbsp;Katzke<BR>Systems&nbsp;Analyst&nbsp;II<BR>TAMU&nbsp;-&nbsp;DRGS<BR><BR><BR><BR><BR><br><br>&gt;&gt;&gt; Andrew Beekhof &lt;andrew@beekhof.net&gt; 5/8/2009 6:26 AM &gt;&gt;&gt;<br>On Thu&#44; May 7&#44; 2009 at 10:24 PM&#44; Mark Hamzy &lt;hamzy@us.ibm.com&gt; wrote:<br>&gt; andrew@beekhof.net wrote on 05/07/2009 17:06:23 PM:<br>&gt;&gt; On Wed&#44; May 6&#44; 2009 at 11:32 PM&#44; Mark Hamzy &lt;hamzy@us.ibm.com&gt; wrote:<br>&gt;&gt; &gt;<br>&gt;<br>&gt;&gt; This is where the disconnect is.<br>&gt;&gt; You seem convinced that everyone will want to sum them up the same way<br>&gt;&gt; you do&#44; for every resource in the cluster.<br>&gt;&gt; I&#39;m not so sure.<br>&gt;<br>&gt; Which is why I wrote the following:<br>&gt;<br>&gt;&gt; &gt; How about a PE option for pacemaker to automatically calculate health&#63;<br>&gt;&gt; &gt; Admins could then enable these calculations if they do not want to go<br>&gt;&gt; &gt; through the effort to investigate all of the health variables and how<br>&gt;&gt; &gt; they might affect system operations&#63;<br>&gt;<br>&gt; Is putting code into pacemaker&#44; so that system health is automatically<br>&gt; calculated &#40;when requested&#41;&#44; something that the community wants&#63;<br><br>Oh I don&#39;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&#44; is to also consider those for which the simplistic<br>model doesn&#39;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&#39;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 &#40;defaults to -INFINITY&#41;&#44;<br>- node-health-score-yellow &#40;defaults to 0&#41;&#44;<br>- node-health-score-green &#40;defaults to 0&#41;&#44;<br><br>These would work like the INFINITY an -INFINITY aliases &#40;see char2score&#40;&#41;&#41;.<br>So &quot;red&quot;&#44; &quot;yellow&quot; and &quot;green&quot; 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&#39;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>&#40;One would probably look up this value and set node-weight during<br>unpack_nodes&#40;&#41; &#41;<br>I still debating whether this is suitable for 1.0<br><br><br>So now the constraints now look like:<br><br>&lt;rsc_location id&#61;&quot;other_health&quot; rsc&#61;&quot;X&quot;&gt;<br>&#160;&#32;&lt;rule id&#61;&quot;health_location_1&quot; score-attribute&#61;&quot;&#35;health-ipmi&quot;/&gt;<br>&#160;&#32;&lt;rule id&#61;&quot;health_location_2&quot; score-attribute&#61;&quot;&#35;health-smart&quot;/&gt;<br>&lt;/rsc_location&gt;<br><br>Which one would only have to specify once for 1.2 when pattern<br>matching gets added &#40;thats definitely not a change for a stable<br>series&#41;.<br><br>I don&#39;t consider this a huge configuration overhead&#44; BUT&#44; I wouldn&#39;t<br>object to adding<br>- node-health-strategy &#61; &#40;none&#44; custom&#44; migrate-on-red&#44; ...&#41;<br><br>&#42; &quot;none&quot; would be the default<br>&#42; &quot;custom&quot; would require the admin to configure the rsc_location<br>constraints manually<br>&#42; &quot;migrate-on-red&quot; would be the one you&#39;re proposing and implicitly<br>create the relevant rsc_location constraints behind the scenes.<br>&#160;&#32;I&#39;d not call it &quot;automatic&quot; in order to allow us to add other<br>&quot;default&quot; strategies in the future.<br><br>To me this seems like a good compromise between ease-of-use and<br>flexibility&#44; with a sane progression from &quot;none&quot;&#44; to default<br>strategies&#44; to &quot;custom&quot;.<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>