[widar-wg] Alerts - CM - configuration failure

[Bill Sahr]

Pls see below

Sonja Vrcic wrote:
> Bill,
> There is a proposal to add Config ID to Alert ID. When reporting 
> configuration failure for configID=ABCD.1234567.4 for the WIDAR board 
> b101-t-7, Alert ID would look (more-or-less) like this:
> mccc-cm-config-failed-b101-t-7-ABCD.1234567.431
> 
> 
> Note: Alert 'config-failed' will be cleared next time when the board is 
> successfully configured. Successful configuration may have a different 
> Config ID. (If clear alert is going to specify config ID, it would be 
> more useful to identify the successful configuration).
> 
> Perhaps, clear alert should not specify config ID (or specify an empty 
> string). The same may apply for the failure that occurred while 
> de-configuring (transmitting the default configuration).

My opinion is that the clear alert should specify the config ID & that
it should specify the config-ID for which the alert was originally raised.
Reasons - a clear alert should match the alert that was raised.  Anything
else is confusing.  If the config failed for ABCD.1234567.431 then the
clear alert for that raised alert should specify ABCD.1234567.431.

I've checked my old email exchanges with Rich, and, yes, if you want these
alerts to be archived, then the "archive" element with at least the
required attributes must be included in the Alerts message.

Bill

> 
> Raise alert for config ID=ABCD.1234567.4
> mccc-cm-config-failed-b101-t-7-ABCD.1234567.4
> 
> Clear alert
> mccc-cm-config-failed-b101-t-7
> 
> Raise alert for default configuration
> mccc-cm-config-failed-b101-t-7
> 
> But, this would require alarm processing s/w to parse Alert IDs.
> 
> Sonja
> 
> 
> 
> 
> 
> Bill Sahr wrote:
>> Pls see below.
>>
>> Sonja Vrcic wrote:
>>   
>>> Michael,
>>> thanks for the quick response, please see my comments below.
>>> Sonja
>>>
>>>
>>> Michael Rupen wrote:
>>>      
>>   
>>> My understanding is that operator can see only one alert of the same
>>> type on the screen. If that is true, and CM implements a) operator would
>>> see only the last generated alert (config ID). Therefore b) seems to be
>>> a better solution.
>>>
>>> Config ID could be added to the alert message as a parameter. Since
>>> alert can have multiple parameters, CM could add two or more config IDs
>>> to the same alert.
>>> But, is it possible to display one or more config IDs on the operator
>>> screen.
>>> And, if specified as parameter(s), would config ID(s) be added to the
>>> archive.
>>>
>>>      
>> If specified as a parameter, I don't think config IDs would be archived.
>> To be archived, I think one would have to specify the config ID as an
>> attribute of the "archive" element, perhaps as "mon".
>>
>> There is another option not yet discussed - there is a variant form of
>> monitor data being used for the vlba that describes the monitor point
>> data table as:
>>
>>   
>>> hostname varchar(20) not null,
>>> devicename varchar(20) not null,
>>> monpointname varchar(30) not null,
>>> timestamp double precision not null,
>>> status int2 not null,
>>> monpointvalue double precision not null,
>>> monpointstr  varchar(20),
>>> dtype  int2  not null
>>>      
>> monpointstr&  dtype are the variant fields.  If these fields were 
>> included
>> as attributes in the archive element&  in the alertdata table in the
>> database, then config ID could be set as the value of monpointstr.
>> Of course, adding these fields to the archive element would mean 
>> modifying
>> the xAlerts schema.
>>
>> Bill
>>
>>    
>