[MCOL-436] Alarms is being incorrect processed on local node Created: 2016-12-05  Updated: 2018-02-08  Resolved: 2018-02-08

Status: Closed
Project: MariaDB ColumnStore
Component/s: None
Affects Version/s: 1.1.2
Fix Version/s: 1.1.3

Type: Bug Priority: Minor
Reporter: David Hill (Inactive) Assignee: Daniel Lee (Inactive)
Resolution: Fixed Votes: 0
Labels: None

Sprint: 2018-03

 Description   

When testing in the multi-node AWS environment, I noticed that each node had alarms logged in the log directory. This should be the case, all alarms should be processed on the Active Parent OAM Module, which is the module where ProcMgr is running.

When alarms was processed as part of an SNMP-TRAP, it was correct processed on the Active Parent OAM Module because that is where the snmptrapd was running.

Due to the changes to go away from issue snmptraps and just issue alarms, this logic was lost causing the alarms to be process on each local node.

A change is need to have the alarms routed to Procmgr and it would process them. This will cause the processing on the Active Parent OAM Module, like they should do doing



 Comments   
Comment by David Hill (Inactive) [ 2018-02-02 ]

added logic to send all alarm request to procmgr soall alarms are getting processed on the Parent OAM module...

soak testing now

Comment by David Hill (Inactive) [ 2018-02-02 ]

fixed with this pull request

https://github.com/mariadb-corporation/mariadb-columnstore-engine/pull/394

Comment by David Hill (Inactive) [ 2018-02-02 ]

how to test. run a multi-node system, you will only see alarm logs on the modulewhere procmgr is running

Comment by David Hill (Inactive) [ 2018-02-02 ]

fix

1. all alarm set/clear request sent to procmgr
2. procmgr now has a dedicated port to receive and serially process alarm request. this will prevent the file corruption issue

Comment by Daniel Lee (Inactive) [ 2018-02-08 ]

Build verified: 1.1.3-1 AMI released to QA on 2/7/2018

Performed 1um2pm installation and verified alarm entries.

Generated at Thu Feb 08 02:21:03 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.