<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <font face="Calibri">With the merge of Hawkular-922 we've moved
      trigger definition out of the UI code and into the server.  This
      simplifies the UI coding but more importantly it means users don't
      need to log in and perform UI navigation in order to initiate
      alerting.  Now, as soon as the agent discovers resources, and
      inventory notifies the bus, triggers are defined.   These
      out-of-box (OOB) triggers will now monitor data prior to any user
      login.<br>
      <br>
      Moreover, our OOB triggers are now defined as Group triggers (the
      H-Alerts equivalent to Alert Definition Templates in RHQ).  So,
      for new Resource-Types we define Group triggers, and then for each
      new Resource of those types we add a member trigger to the group. 
      In alpha-10 we maintain nearly the same UI wrt alerts, but one big
      difference is that editing a trigger definition now affects all
      members of that group.  So, for example, if you change a CPU
      trigger from &gt; 20% to &gt; 30% it will actually change all of
      the CPU triggers in the same way.  If you want to disable NonHeap
      triggers you can disable then all at one time. Etc.. This gets us
      closer to a "policy" approach to alerting where everything is
      monitored in the same fashion.<br>
      <br>
      There is another change to mention that makes sense but may seem a
      little surprising.  Because the OOB triggers are now defined
      server-side, outside of a UI session, there is no obvious user
      associated with their creation. In the UI we had the user that was
      logged in at the time but on the server, but now we don't.  </font><font
      face="Calibri"><font face="Calibri">Because we don't have an email
        address </font>it's not possible to define an email action at
      trigger creation time .  For now, to activate an email action it
      will require a UI session and an edit of the trigger.  The email
      will be applied to all of the triggers in that group (not all
      triggers in the system).  There is a new on/off switch on the
      email action and it will initially be set to off.<br>
      <br>
      It's unclear where we go from here, but if there is further work
      in this area there are several things to discuss, like:<br>
      - a more robust [email] action approach<br>
      - ad-hoc group triggers<br>
    </font><font face="Calibri"><font face="Calibri">- detaching members
        from groups<br>
      </font>- ad-hoc [standard] triggers<br>
      <br>
      Jay<br>
    </font>
  </body>
</html>