beorn7 22db73fbf7 Modify the self-inhibition prevention semantics ... This has been discussed in #666 (issue of hell...). As concluded there, the cleanest semantics is most likely the following: "An alert that matches both target and source side cannot inhibit alerts for which the same is true." The two open questions were: 1. How difficult is the implementation? 2. Is it needed? This relatively simple commit proves that the answer to (1) is: Not very difficult. (This also includes a performance-improving simplification, which would have been possible without a change of semantics.) The answer to (2) is twofold: For one, the original use case in #666 wasn't solved by our interim solution. What we solved is the case where the self-inhibition is triggered by a wide target match, i.e. I have a specific alert that should inhibit a whole group of target alerts without inhibiting itself. What we did _not_ solve is the inverted case: Self-inhibition by a wide source match, i.e. an alert that should only fire if none of a whole group of source alert fires. I mean, we "fixed" it as in, the target alert will never be inhibited, but @lmb in #666 wanted the alert to be inhibited _sometimes_ (just not _always_). The other part is that I think that the asymmetry in our interim solution will at some point haunt us. Thus, I really would like to get this change in before we do a 1.0 release. In practice, I expect this to be only relevant in very rare cases. But those cases will be most difficult to reason with, and I claim that the solution in this commit is matching what humans intuitively expect. Signed-off-by: beorn7 <beorn@soundcloud.com>		2019-02-25 16:10:08 +01:00
..
inhibit_test.go	Modify the self-inhibition prevention semantics	2019-02-25 16:10:08 +01:00
inhibit.go	Modify the self-inhibition prevention semantics	2019-02-25 16:10:08 +01:00