Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

persist event notifier service boots #386

Merged
merged 1 commit into from
May 31, 2022
Merged

Conversation

emesika
Copy link
Member

@emesika emesika commented May 23, 2022

This bug is a result of applying level 3 security of the new USM
introduced on SNMP V3.
When the Event Notification Service is restarts , it creates a new USM
object but does not update the number of time its was rebooted.
This makes the service suspected by SNMP V3 and it stops getting traps
from it in snmptrapd.
The solution is to add a new configuration value
NotificationServiceBoots which is set by default to 0.
Each time the Event Notification Service is rebooted, this value is
incremented by 1 and stored in the configuration table (vdc_options)

When a new USM object is created on Event Notification Service run
method, it set the number of boots accordint to the persisted value.

This solves the problem and Event Notification Service can be restated
several times and still keep getting traps on which it is listening
according to its "FILTER" settings.

Signed-off-by: Eli Mesika emesika@redhat.com
Bug-Url: https://bugzilla.redhat.com/2072626

This bug is a result of applying level 3 security of the new USM
introduced on SNMP V3.
When the Event Notification Service is restarts , it creates a new USM
object but does not update the number of time its was rebooted.
This makes the service suspected by SNMP V3 and it stops getting traps
from it in snmptrapd.
The solution is to add a new configuration value
NotificationServiceBoots which is set by default to 0.
Each time the Event Notification Service is rebooted, this value is
incremented by 1 and stored in the configuration table (vdc_options)

When a new USM object is created on Event Notification Service run
method, it set the number of boots accordint to the persisted value.

This solves the problem and Event Notification Service can be restated
several times and still keep getting traps on which it is listening
according to its "FILTER" settings.

Signed-off-by: Eli Mesika <emesika@redhat.com>
Bug-Url: https://bugzilla.redhat.com/2072626
Copy link
Member

@mwperina mwperina left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

@mwperina mwperina merged commit d4af9a4 into oVirt:master May 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants