Created attachment 882381 [details] events + descriptions from DB Provide a text file that documents all messages event notifier can send. Text file should include message ID and Message description. Notifier configuration file should specify, in a #comment next to filter documentation, file's path. This RFE is to produce an initial text file from existing list of events and descriptions in database [Image Attached] Description of problem: Currently the only way to use events notifier filters is to send all messages(not filter) to a SNMP server, and then, only after nasty events happen, produce a list of event IDs to filter-out or accept them.
Because this file is currently maintained by hand as it is needed asap, it should be merged just before releasing next version.
Automating this might prove too complicated: we have all the the events names and descriptions in LocalizedEnums.properties but in order to divide them to catagories we need to inspect VdcEventNotificationUtils as well.
(In reply to Arthur Berezin from comment #0) > Created attachment 882381 [details] > events + descriptions from DB > > Provide a text file that documents all messages event notifier can send. > Text file should include message ID and Message description. > Notifier configuration file should specify, in a #comment next to filter > documentation, file's path. > There is an internal contridiction in the description: - "Provide a text file that documents all messages event notifier can send" - "Text file should include message ID and Message description" As not all events has description - the only events that have description are maintained by the UI group (~100 out of ~800), So as we don't want to do a partial work or do duplicate work for next version as well, there are 2 approaches: 1 - for PMs & Devel to provide all the descriptions for the rest of ~700 events 2 - replace description with the actual text that is sent with every event (can be found @ https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/dal/src/main/resources/bundles/AuditLogMessages.properties I prefer option #2 for few reasons: #1 is not practical to achieve for the 3.4 time frame #2 will have all the events (and the default is sending all the events) #2 will be auto generated during build time #2 will enable the user to see the message structure and parameters he will receive in the notification and enable him to easily parse it for his use. Actually we can take that file entirely and publish it under the docs
(In reply to Barak from comment #3) > (In reply to Arthur Berezin from comment #0) > > Created attachment 882381 [details] > > events + descriptions from DB > > > > Provide a text file that documents all messages event notifier can send. > > Text file should include message ID and Message description. > > Notifier configuration file should specify, in a #comment next to filter > > documentation, file's path. > > > > There is an internal contridiction in the description: > - "Provide a text file that documents all messages event notifier can send" > - "Text file should include message ID and Message description" > > As not all events has description - the only events that have description > are maintained by the UI group (~100 out of ~800), > > So as we don't want to do a partial work or do duplicate work for next > version as well, there are 2 approaches: > 1 - for PMs & Devel to provide all the descriptions for the rest of ~700 > events > 2 - replace description with the actual text that is sent with every event > (can be found @ > https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/ > dal/src/main/resources/bundles/AuditLogMessages.properties > > I prefer option #2 for few reasons: > #1 is not practical to achieve for the 3.4 time frame > #2 will have all the events (and the default is sending all the events) > #2 will be auto generated during build time > #2 will enable the user to see the message structure and parameters he will > receive in the notification and enable him to easily parse it for his use. > > Actually we can take that file entirely and publish it under the docs +1 for option #2.
"Actually we can take that file entirely and publish it under the docs" docs would mean /usr/share/docs/ right ?
(In reply to Arthur Berezin from comment #5) > "Actually we can take that file entirely and publish it under the docs" > > docs would mean /usr/share/docs/ right ? Yes
ok, av8. # rpm -qf /usr/share/doc/ovirt-engine/AuditLogMessages.properties rhevm-backend-3.4.0-0.16.rc.el6ev.noarch # head /usr/share/doc/ovirt-engine/AuditLogMessages.properties VM_CLEARED=Unused SYSTEM_MASTER_DOMAIN_NOT_IN_SYNC=Sync Error on Master Domain between Host ${VdsName} and oVirt Engine. Domain: ${StorageDomainName} is marked as Master in oVirt Engine database but not on the Storage side. Please consult with Support on how to fix this issue. IRS_DISK_SPACE_LOW=Warning, Low disk space.${StorageDomainName} domain has ${DiskSpace} GB of free space IRS_DISK_SPACE_LOW_ERROR=Critical, Low disk space. ${StorageDomainName} domain has ${DiskSpace} GB of free space VDS_LOW_DISK_SPACE=Warning, Low disk space. Host ${VdsName} has less than ${DiskSpace} MB of free space left on: ${Disks}. VDS_LOW_DISK_SPACE_ERROR=Critical, Low disk space. Host ${VdsName} has less than ${DiskSpace} MB of free space left on: ${Disks}. IRS_FAILURE=Failed to access Storage on Host ${VdsName}. USER_ADD=User '${NewUserName}' was added successfully to the system. USER_FAILED_ADD_ADUSER=Failed to add User '${NewUserName}' to the system. USER_ADD_BOOKMARK=Bookmark ${BookmarkName} was added by ${UserName}.
Closing as part of 3.4.0