... | ... | @@ -101,4 +101,12 @@ The design of the table allows filtering entries by related entity or entity typ |
|
|
|
|
|
### Subscriber / Web Browser / UI
|
|
|
|
|
|
When user in web browser enters particular page in Stork Web UI, the code of this page should subscribe to events that this page is interested in. If this is e.g. machines page it should subscribe to events related to machines. IF this is a page of particular application it should subscribe to events connected with this application. If this is the main dashboard then it should subscribe to all events. Each page should read the events that are sent to them and update the UI accordingly. |
|
|
\ No newline at end of file |
|
|
When user in web browser enters particular page in Stork Web UI, the code of this page should subscribe to events that this page is interested in. If this is e.g. machines page it should subscribe to events related to machines. IF this is a page of particular application it should subscribe to events connected with this application. If this is the main dashboard then it should subscribe to all events. Each page should read the events that are sent to them and update the UI accordingly.
|
|
|
|
|
|
### Open questions
|
|
|
|
|
|
1. Are the rules persistent, i.e. as an admin I log in, set a rule to get alert about X, then log out, X happens, after some time I log in. Will I see a notification?
|
|
|
|
|
|
2. I think we need to manage the event types somehow. There will be a lot of them very soon. A separate table with event types? It should be easily extensible, possibly by different independent devs.
|
|
|
|
|
|
3. Don't assume that SSE will be the only way to consume alerts. It will be for a while, but later down the road we may integrate with some existing notification systems, like [prometheus' altermanager](https://prometheus.io/docs/alerting/alertmanager/) or [stackexchange's bosun](https://bosun.org/). |
|
|
\ No newline at end of file |