[evla-sw-discuss] Alert server

[Barry Clark]

We've always been unclear on the concept of stale alerts (note included
message at the end of this.

Now that we have an alert server, it should take care of things in a 
better way.  But, as illustrated by the incident below, it has merely
gone from alerts being erroneously overlooked to alerts being erroneously
preserved.

The alert server is perfectly capable of going out to the monitor point
and asking if the alert is still in force.  It should do so.  Question
is when.  Could be done periodically, on a slow period.  Or, the Executor,
whenever a new script starts, could send a REST message to the alert 
server, saying "Here is my ID.  Please check and see if any alerts you
have for me are still valid."

> From evlatests-bounces at donar.cv.nrao.edu  Wed Jul 11 14:14:22 2007
> Date: Wed, 11 Jul 2007 14:14:04 -0600 (MDT)
> From: Ken Sowinski <ksowinsk at nrao.edu>
> To: evlatests at nrao.edu
> 
> There was much confusion at the VLA today with regard to timing
> between the arrays whcih ened with the CMP in a strange state
> and having to be rebooted more than once.  This resulted in
> stale "L8 out of sync" messages in the alert server causing
> all data from VLA antennas to be flagged as bad.
> 
> AS a temporary measure Walter has kludged idcaf so that L8
> alertsd are not turned into flags.  However the alerts are
> still there and no one I have talked to knows how to make
> them go away.  We need either a little more distributed
> knowledge about these parts of the system, or a system
> with less remembered state.  I wonder if some (certainly not
> all) of our problems with bad flagging may be related to this
> kind of behavior.
> 
> Notice of removal of these alerts would be appreciated so that
> idcaf can be restored to its usual funtionality.
> 
> _______________________________________________
> evlatests mailing list
> evlatests at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evlatests
>