Formal alarm handling from xApps and from RICplatform, excluding actual alarms
Description
Note that as of May-7 we only have a go library for rasing alarms, C++ and python we don't have. First one needing it could implement this library based on the go example.
We might change the title once we have the health check use case clarified
Note that xApps might report alarms using RMR (to avoid a sidecar solution).
Includes:
xApp can raise/clear alarm
platform components can raise/clear alarm
new component that manages alarms - ideally re-using Prometheus alert manager, but keep solution in a way that other alarm managers could be used.
O1 mediator makes list of active alarms visible via netconf and VES events sent for alarm changes.
To be defined some platform alarms
Send a heartbeat alarm/notification via VES
By early february we should have a list (by name) of alarms we want to work on in Bronze. Thsi list is to be sent to Martin Sko... (highstreet). We now have RIC-585, RIC-203, RIC-204 as candidates, but all are stretch goals for Bronze.
Note one option is that the alarm library (to be used by xApps and platform compornents) can be controlled by an environment variable to (a) send alarm structure via RMR or (b) send a log to stdout).
Attachments
1
0% Done
Activity
Show:
Thoralf CzichyNovember 12, 2020 at 1:37 PM
Edited
I now mark this as done as the overall framwork is ready. However we still do not actually have any actual platform alarm. This can be tested by raising an artificial alarm using a CLI, or by using the QP driver xApp that raises an alarm if it cannot connect to the SDL. The first actual alarms we might implement are now upgraded from user story to Epic. Which should make it easier to manage them: , ,
Matti HiltunenSeptember 2, 2020 at 2:16 PM
The QP-driver xApp already raises an alarm if the SDL layer is not accessible. Not sure if the RIC platform will do anything with it.
Puhakka, Antti (Nokia - FI/Espoo)April 29, 2020 at 7:08 AM
Common part has been done. I will assign this to someone else.
Thoralf CzichyFebruary 24, 2020 at 8:20 AM
discussed te item with on how to implement this. Likely he will come up with the API over the next few weeks.
Thoralf CzichyFebruary 11, 2020 at 2:35 PM
Martin's project will create the RIC specific yang based on alarm titles and we can demonstrate using the SIM project that it works on OAM level. Need to keep him up to date if we can't implement all draft alarms.
Note that as of May-7 we only have a go library for rasing alarms, C++ and python we don't have. First one needing it could implement this library based on the go example.
We might change the title once we have the health check use case clarified
Note that xApps might report alarms using RMR (to avoid a sidecar solution).
Includes:
xApp can raise/clear alarm
platform components can raise/clear alarm
new component that manages alarms - ideally re-using Prometheus alert manager, but keep solution in a way that other alarm managers could be used.
O1 mediator makes list of active alarms visible via netconf and VES events sent for alarm changes.
To be defined some platform alarms
Send a heartbeat alarm/notification via VES
By early february we should have a list (by name) of alarms we want to work on in Bronze. Thsi list is to be sent to Martin Sko... (highstreet). We now have RIC-585, RIC-203, RIC-204 as candidates, but all are stretch goals for Bronze.
Note one option is that the alarm library (to be used by xApps and platform compornents) can be controlled by an environment variable to (a) send alarm structure via RMR or (b) send a log to stdout).