Hi Maryam,

Just going to chime in here as I am want to do on occasion, more or less 
reiterating Alok’s answers but including long and tedious reasoning.

For events I tend to think the events should be reported at a relative level of 
importance from the reporting function.  If my role in the system is to 
maintain a link and that link goes down this is a pretty big thing for me in my 
role.
Aggregation/normalization of the severity of the event should then be handled 
by an aggregative function that understands the context of the notification in 
a broader context.

I guess in my opinion if a link is down I would expect a switching function 
would be issuing a warning or error level event.  The “collector” or host 
application of that function may adjust that level in the context of functional 
redundancy or aggregation.  If the application is aware of the role of the 
switch in the overall system it may inform the switch of how to report these 
events, so configurability would seem a useful function to reduce event 
processing overhead.

/ Chris

On 2016-11-08, 07:51, "[email protected] on behalf of 
Tahhan, Maryam" <[email protected] on behalf of 
[email protected]> wrote:

     Hi Folks
     
     For the OVS events collectd plugin we wrote as part of barometer, we are 
currently sending a notification message from collectd with a level that is set 
to WARNING for when the link status is detected to be down. So this means that 
when the status changes from "Unknown" to "down" when a new interface is added 
a warning message will be generated. 
    
    
    So from a Doctor/VES perspective:
     1. When do you expect to see a warning message vs an informational 
message? When the link status only changes from Up to down 
    
     2. Do you want to know when the status changes from unknown to down?
    
     3. Should we allow the notification severity to be configurable for link 
status? Or should we from a collectd point of view provide you with 
informational messages only and let you decide a severity?
     
     BR
     Maryam
    _______________________________________________
    opnfv-tech-discuss mailing list
    [email protected]
    https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
    

_______________________________________________
opnfv-tech-discuss mailing list
[email protected]
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Reply via email to