Suppress alarms/tickets on initial import of a device / interface

[runborg]

When a new device is added to zino without any prior nown state to zino, the server will generate tickets on all interfaces in down state.
These alarms are 99% of time alarms that we do not need and on a new instance of zino this will generate thousands of alarm that the user needs to manually close.

There should be a way to suppress these alarms on the initial run as they are usually not needed.

[runborg]

This could be a true/false option in config?

[lunkwill42]

Håvard wanted to design an algorithm for this in Zino 1 first, but that may not be relevant to how it would work in Zino 2, since the internal data structures are built entirely different.

While this functionality does not constitute feature parity with Zino 1, it may actually be important to implement in Zino 2.0 (not post-2.0) for new users to adopt it: The issues described will mostly affect those who start Zino for the first time (i.e. with no prior state).

I can add the anecdote that if we start Zino 2.0 with the full polldevs.cf of the Uninett research network (~230 routers) and no prior state file, Zino opens nearly 8000 events in the first five minutes. When adding one production router at a time, over a period of nearly 30 years, and closing the events one router at a time, it doesn't seem like much, but do it all at once, and it's a huge undertaking.

[lunkwill42]

I might add that Håvard suggested we might do this as a config switch, but that that suppression should probably be switched on by default in the new version.

Håvard suggested that he finds it comforting that these events are opened when a new router is added, as it serves somewhat as a verification that the router is now being successfully monitored by Zino. He added that it might be interesting to instead add a new type of event that only conveys that a new router has appeared on the monitoring list (i.e. adding 230 routers in a go would open 230 new-device events). I think this might serve as a separate, post-2.0 issue.