You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we have alarm descriptions stored in two places: the registered alarms topic of Kafka, plus a wiki linked via the docurl field. The wiki duplicates nearly all of the same information and they're currently out-of-sync and alarms are categorized differently. If we add the fields "response/action", "point of contact", and "rationale" to the registered alarms topic we'd have all the same fields. It sounds like we want an admin GUI anyways to make it easy for users to add and manage alarms. For example, configuring the "suppressed by" tree could be done in the admin GUI. At that point, you might as well input the rationale, actions, and point of contact to complete all data. The wiki becomes extraneous and unnecessary, and a searchable viewable web page of alarms could easily be constructed from the kafka data (or admin GUI could probably do that too). Operators client GUI could easily access the data too without popping open a web browser to a Wiki.
The text was updated successfully, but these errors were encountered:
slominskir
changed the title
Consolidate registered alarms data
Consolidate registered alarms data and import existing alarms
Mar 16, 2022
However, we have recently moved the data into an Oracle database as part of the admin GUI.
Still to consider is if we need some automated sync from the existing alarm system to JAWs to keep it up-to-date or else a manual sync periodically done until the switch over. Further an automated sync from the CED may be useful.
Currently we have alarm descriptions stored in two places: the registered alarms topic of Kafka, plus a wiki linked via the docurl field. The wiki duplicates nearly all of the same information and they're currently out-of-sync and alarms are categorized differently. If we add the fields "response/action", "point of contact", and "rationale" to the registered alarms topic we'd have all the same fields. It sounds like we want an admin GUI anyways to make it easy for users to add and manage alarms. For example, configuring the "suppressed by" tree could be done in the admin GUI. At that point, you might as well input the rationale, actions, and point of contact to complete all data. The wiki becomes extraneous and unnecessary, and a searchable viewable web page of alarms could easily be constructed from the kafka data (or admin GUI could probably do that too). Operators client GUI could easily access the data too without popping open a web browser to a Wiki.
The text was updated successfully, but these errors were encountered: