Allow run_every to be unique per rule #2593
Conversation
|
@Qmando is there any blocker for this PR to be merged? |
|
@Qmando thank you, sir! 🎉 |
|
Hi, does the restriction of elasticsearch==7.0.0 means we cannot run against any other el version? I have a cluster in 7.5.1 so initially was forcing the elasticsearch library to 7.5.1 but after upgrading elastalert to 0.2.4 it fails. |
|
What does "it fails" mean exactly |
|
requirements are set to force elasticsearch==7.0.0 so it complains if I have 7.5.1 |
|
Try I'm not sure exactly what conditions cause this but I think it's certain versions of setuptools (or pip? idk) create a link (the elastalert binary) that force all packages to match exactly. Could you share the exact error message so I can narrow it down? I can't reproduce that problem. |
|
yep that did the trick indeed, thanks didn't know about differences how python libs are checked 👍 |
|
@Qmando Please help! |
|
+1 looking for this feature to work. |
Fixes #497
It's currently copying run_every as part of the "default rule properties", which used to be a set of things that are not configurable by the rule yaml itself. This was never removed despite run_every becoming a per rule property.
Several tests were relying on this because they are mocking out the config loader, which also adds a default run_every, and not specifying one.
I added a test for specifically this feature, and confirmed that without the changes to elastalert.py, that new test fails.
As a bonus, I've included a fix for #2580, because I haven't created a separate PR for it yet. This allows nested query keys to work in top_count_keys.
Also note: I also added a pin for elasticsearch==7.0.0, because apparently 7.1.0 will NOT work with ES < 6.6 due to it not supported _source_include(s?). 7.0.0 does. Tests won't pass otherwise.