-
Notifications
You must be signed in to change notification settings - Fork 295
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bot option: Error Forward Message #1133
Conversation
I changed the target branch to develop because this is a new feature. Have a look at https:/certtools/intelmq/blob/master/docs/Developers-Guide.md#branching-model maintenance only get's bugfixes and master is always the latest release (nothing between stable versions) Please add this to the changelog (in the 1.1 core section). |
@aaronkaplan I added you because I'd like if the name of the parameter is intuitive. I am not sure if it is. The relevant change is in 89574ff |
Thank you @wagner-certat for the clarification. I tried to rebase but with no luck. Could you provide the commands to perform that operation successfully? Thank you. |
As the branch you branched off was very old too (at the stage of the 1.0.0 RC), cherry-picking is faster: First update your local branch:
If you have a develop branch locally, assuming that upstream is the remote pointing to certtools (depends on your local configuration):
If you don't have develop locally yet:
Copy the old branch, delete the existing and make it a copy of develop:
And now pick the commit to the new branch:
You will get a conflict in
Now upload that branch:
If everything went fine, you can delete the backup branch. |
89574ff
to
4cf7401
Compare
@wagner-certat Thank you! It works. |
Codecov Report
@@ Coverage Diff @@
## develop #1133 +/- ##
===========================================
+ Coverage 75.81% 75.82% +0.01%
===========================================
Files 231 231
Lines 10892 10909 +17
Branches 1447 1448 +1
===========================================
+ Hits 8258 8272 +14
- Misses 2306 2309 +3
Partials 328 328
|
Great, looks good. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You must not forward bogus messages for parser and output bots. So it only applies to experts.
@aaronkaplan has some comments too
intelmq/lib/bot.py
Outdated
@@ -213,6 +213,10 @@ def start(self, starting: bool=True, error_on_pipeline: bool=True, | |||
|
|||
if error_on_message: | |||
|
|||
if self.parameters.error_forward_message: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For upgrades this parameter won't exist, you need to have a fallback (use getattr)
@wagner-certat the current travis error is regarding the Thank you in advance. |
Currently it is a "parameter", i.e. user-defined. That does not make sense for the POV from intelmq itself, because it is defined by the bot type.
|
@sebix check if everything is ok please. Thank you! :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code is ok for me.
Still waiting for @aaronkaplan's comments
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure if I think this is a good idea to implement it so generically. Why?
Because if you just want to skip let's say failed DNS queries, then you actually implemented it in a very generic way here.
But if it's implemented so generically, it will be abused.
And if someone configures this and is wondering why the data is not there for "downstream" bots, then ... it's hard to debug.
So... I am definitely for "if it breaks, break early and fix it specifically at that bot".
This suggestion makes intelMQ potentially harder to debug.
But... we are discussing in chat. Maybe it's possible to accommodate easily and intuitively
@@ -109,6 +109,9 @@ You can set these parameters per bot as well. The settings will take effect afte | |||
* **`error_dump_message`** - specifies if the bot will write queued up messages to its dump file (use intelmqdump to re-insert the message). | |||
* **`true/false`** - write or not write message to the dump file | |||
|
|||
* **`error_forward_message`** - specifies if the bot will forward messages to output queue which couldn't be processed by the bot. This option MUST be only used by Expert Bots. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
non intuitive name.
how about:
event_always_passthrough
.... pass through the event in any situation, even when errors exist in the expert.
@@ -6,6 +6,7 @@ | |||
"destination_pipeline_password": null, | |||
"destination_pipeline_port": 6379, | |||
"error_dump_message": true, | |||
"error_forward_message": false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see above.
We definitely need a comment here! This can have pretty bad effects if turned on.
@@ -211,6 +217,10 @@ def start(self, starting: bool=True, error_on_pipeline: bool=True, | |||
|
|||
if error_on_message: | |||
|
|||
if self.parameters.error_forward_message and self.group == "Expert": | |||
self.logger.info("Forwarding message to output queue.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
self.logger.info ("Forcing forwarding of message even in case of errors")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another comment: I believe it is much much better to add a 2> /tmp/errors and > /tmp/ok style output switch similar to nifi:
So, basically , one queue for "ok" events, one queue for "not ok events" where the expert could not do anything. Now if the user clearly says that both output queues should be the same, then that's ok.
Then you have your behaviour
This could be a use case for #1088 |
error_forward_message
is an option for Expert bots. Bots like gethostbyname sometimes raise some errors which are only due some service problems like DNS nameserver for a specific domain is replying SERVFAIL. Therefore, with this new option, intelmq administrator can configure an expert bot to forward the original message to the next bot automatically after X retries configured as usual.