Skip to content
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.

Sign up for GitHub

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

Jump to bottom

IndicesRecovery runner runs with 1 iteration and ends abruptly #796

Closed
dliappis opened this issue Oct 16, 2019 · 0 comments · Fixed by #800
Closed

IndicesRecovery runner runs with 1 iteration and ends abruptly #796

dliappis opened this issue Oct 16, 2019 · 0 comments · Fixed by #800
Assignees
@danielmitterdorfer
Labels
bug Something's wrong :Load Driver Changes that affect the core of the load driver such as scheduling, the measurement approach etc.
Milestone
1.4.0

Comments

@dliappis
Copy link
Contributor

The new IndicesRecovery runner introduced in #793 (used by the wait-for-recovery operation) seems to use an iteration-count based schedule with 1 iteration. As a result it runs once, (calculates percent_completed correctly) and ends due to the schedule. Logs show:

Creating iteration-count based schedule with [deterministic] distribution for [wait-for-recovery] with [0] warmup iterations and [1] iterations.

My understanding is that since we don't specify iterations or warmup_iterations, based on #requires_time_period_schedule which then sets infinite=True forcing 1 iteration in #schedule_for.

Was it meant to be ran with a custom schedule?

Related: #789 and #763
@dliappis dliappis added this to the 1.4.0 milestone Oct 16, 2019
danielmitterdorfer added a commit to danielmitterdorfer/rally that referenced this issue Oct 17, 2019
@danielmitterdorfer
Properly wait for recovery to finish
478a84d 
With this commit we ensure that a proper schedule is chosen when waiting
for shard recovery to finish. We also ensure that a short time-span where no
recoveries are active (but more might continue soon) is not mistakenly
treated as a condition where all recoveries have already finished.

Closes elastic#796
@danielmitterdorfer danielmitterdorfer added :Load Driver Changes that affect the core of the load driver such as scheduling, the measurement approach etc. bug Something's wrong labels Oct 17, 2019
@danielmitterdorfer danielmitterdorfer mentioned this issue Oct 17, 2019
Merged
danielmitterdorfer added a commit that referenced this issue Oct 21, 2019
@danielmitterdorfer
Properly wait for recovery to finish
2e2d947 
With this commit we ensure that a proper schedule is chosen when waiting
for shard recovery to finish. We also ensure that a short time-span where no
recoveries are active (but more might continue soon) is not mistakenly
treated as a condition where all recoveries have already finished.

Closes #796
Relates #800
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@danielmitterdorfer danielmitterdorfer

Labels
bug Something's wrong :Load Driver Changes that affect the core of the load driver such as scheduling, the measurement approach etc.
Projects
None yet
Milestone
1.4.0
Development

Successfully merging a pull request may close this issue.

Properly wait for recovery to finish danielmitterdorfer/rally
2 participants
@danielmitterdorfer @dliappis