[📦 NEW] -m, --minimum-kill-interval #69
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implements #67
It uses the time intervals introduced with the whitelisting feature. The way it works is once a kill time has been decided, an amount of time between the minimum kill interval before and after the decided kill time is blacklisted. This is required so that the two features can work together and from that point of view, the solution is quite elegant in my opinion. Note that these time intervals are used even when whitelists or blacklists are not used so whitelists don't have to be used in order for minimum kill interval to work.
However, it does still have one quirk. It will work as intended on the first sweep. But when a node is selected the second time for scheduling and from that time onwards, the respective blacklists will extraneously munch away from the active interval in which kill times could have been decided, eventually the interval reaching zero, moment at which it will panic saying that
minimum kill interval is too high
, even though that's not the case. I haven't tested this, I only know this theoretically.The fix might be to schedule a removal of the blacklist interval when the node has died. But since the node might die from external factors (correct me if I'm wrong), this is not the best solution.
Otherwise, the best fix might be to look at all the nodes like @JorritSalverda said in the issue #67 (comment).
I'm unavailable for a few days, I'll sleep on it, I think this pull request is still viable for integration in master as is.