[widar-wg] Alerts - CM - configuration failure

[Sonja Vrcic]

Kevin,
the purpose of my message was to solicit instructions on whether 'clear 
alert' should specify Config ID, and which Config ID it should be (the 
one that was reported when the alert was activated or the one that was 
successful and caused CM to clear the alert).
Thanks,
Sonja


Kevin Ryan wrote:
> As an aside to all of this.
>
> I think that it is good that we discuss this stuff, however I would
> like formatting implementation to NOT be made at the alert source.
> Instead I have created methods that let the alert originator specify
> various details individually for assembly later by a single Alert
> Generator.  I am in the process of modifying these methods to
> accommodate 'configId', 'sid', 'bbid' and 'sbid' (the latter three, I
> would imagine, will be handy for MCAF) in addition to 'host',
> 'process', 'boardId' and 'boardSn' that are currently in use.
>
> WIDAR's EVLA Alert Generator will format these bits of information
> into EVLA alerts that will display properly to the operator and be
> archived correctly.  The processes generating the alerts need only
> supply the details.
>
> Encapsulating alert formatting will allow us to tinker with it with
> minimal impact on the alert source processes.
>
> Kevin
>
> On Jun 3, 2011, at 2:04 PM, Bill Sahr wrote:
>
>    
>> 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
>>>>
>>>>
>>>>          
>>>        
>> ________________________________________________________________________________
>> There is a web page, used as a document repository, associated with
>> this list.
>> The URL for the web page is:
>> http://listmgr.cv.nrao.edu/pipermail/widar-wg/
>>      
>    

-- 
Sonja Vrcic
Software Engineer
Astronomy Technology Research Group - Penticton
National Research Council Of Canada
Herzberg Institute of Astrophysics
Dominion Radio Astrophysical Observatory
Sonja.Vrcic at nrc-cnrc.gc.ca
(250)497-2309 or (250)497-2300 ext.309
http://www.nrc-cnrc.gc.ca/eng/ibp/hia.html