More infrastructure to get the Slack API client working, and a nice golden path established to post to slack when DFS events are observed by the daemon.
Caveats:
we cannot intuitively map from nn to the nn's channel (i.e. #hub-xxxx-nn), so for now there is a static mapping of NN to channel ID. If a DFS event is observed on a nn without this mapping, no slack message will be sent.
If the --enable-slack flag is omitted, the daemon will not attempt to post to slack at all
the slack message formatting could use some love. I suspect we will want to workshop it a bunch to make it high SNR, i.e. by adding links out to the UISP device, graphs/logs, etc from slack directly
Example:
❱ bin/nycmesh-tool daemon --enable-slack
2022/02/08 14:02:53 config file: /home/gabe/.nycmesh-tool.yaml
2022/02/08 14:02:53 binary release v0.4.0-17-ge47d566, built Tue Feb 8 07:02:25 PM UTC 2022
2022/02/08 14:02:53 launching daemon...
2022/02/08 14:02:53 bootstrapping by fetching logs 48h0m0s old
2022/02/08 14:02:53 watching for DFS events with `\bchanged frequency due to DFS detection\b`
2022/02/08 14:03:12 DFS event detected at nn:713 on 2022-02-07T14:18:20.836Z: Device nycmesh-sn3-south main radio changed frequency due to DFS detection
2022/02/08 14:03:12 notifying slack channel C02HZLLH85R of DFS on nn:713 nycmesh-sn3-south
More infrastructure to get the Slack API client working, and a nice golden path established to post to slack when DFS events are observed by the daemon.
Caveats:
nnto the nn's channel (i.e. #hub-xxxx-nn), so for now there is a static mapping of NN to channel ID. If a DFS event is observed on annwithout this mapping, no slack message will be sent.--enable-slackflag is omitted, the daemon will not attempt to post to slack at allExample: