[Response Ops][Task Manager] Integration test for switching between task claim strategies #186419
Conversation
| }, | ||
| { | ||
| name: 'plugins.taskManager.metrics-subscribe-debugger', | ||
| level: 'warn', |
There was a problem hiding this comment.
just to make the tests a little less noisy
ymao1
added
release_note:skip
|
Pinging @elastic/response-ops (Team:ResponseOps) |
There was a problem hiding this comment.
LGTM!
We'll eventually want some more elaborate tests, I think, but they may be painful.
Basically we want to have some tasks in running state when we shutdown the first time, should be easy to arrange with a long-running task. Waiting for it to pick it up to run again - 5m? ouch :-). Likewise, we want some claimed-but-not-yet-running tasks when we shutdown, but I have no idea how we can do that with just Kibana. We may need to write some task docs to the TM index directly, before starting up the second one.
I'm not terribly concerned about these now, but I think we'll need the "claimed-but-not-run" test if we ever go right from idle -> running and skipping marking the tasks as claimed. Something for the future ...
|
Hmm...should I try to add some of those here? Or create follow-up issues for them? I'm not sure I understand the concern about things breaking for claimed but not yet run tasks when switching between task claimers since both claimers use the same |
It might be worth making sure we can re-claim a task that is running when we shutdown, after the 5m wait, if we can cut down the 5m wait somehow (I'm thinking it's not configurable?).
This one we can defer - and I don't think we'll need an issue for it. Mike has been talking about skipping the marking of docs as "claimed"; going straight from "idle" to "running", to try to cut down on # of updates. When we do this, I want to make sure we still LOOK for "claimed" tasks, which we might forget. Should be obvious when we get there ... |
Yeah, and my thinking is we'll still look for expired |
|
Added a test for switching between claimers with tasks that are still running. It adds a delay in the task run function and checks that the task still exists and is |
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]
History
To update your PR or re-run it, just comment with: cc @ymao1 |
…ask claim strategies (elastic#186419) Resolves elastic#184941 ## Summary Adds integration test to verify that restarting Kibana with a different task claim strategy does not break anything and tasks are claimed as expected. --------- Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Resolves #184941
Summary
Adds integration test to verify that restarting Kibana with a different task claim strategy does not break anything and tasks are claimed as expected.