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
overlord: fix TestEnsureLoopPrune not to be so racy #3140
Conversation
We are seeing many failures that involve the TestEnsureLoopPrune test. This test is inherently racy as it uses a actual time to wait for something to happen. In case the machine is loaded heavily and other processes contend for resources it may not get scheduled in time for this to happen. While the fix is not perfect I hope to at least decrease the frequency of the failures. We may investigate a more correct fix where timing would no longer be a factor if this is deemed insufficient. Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
This reverts commit 21d4c1b.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
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.
Nice
overlord/overlord_test.go
Outdated
@@ -370,11 +370,42 @@ func (ovs *overlordSuite) TestEnsureLoopPrune(c *C) { | |||
chg1.AddTask(t1) | |||
chg2 := st.NewChange("prune", "...") | |||
chg2.SetStatus(state.DoneStatus) | |||
t0 := chg2.SpawnTime() |
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.
conceptually this needs to be ReadyTime(), my fault
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'll fix this in a second.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
We are seeing many failures that involve the TestEnsureLoopPrune test.
This test is inherently racy as it uses a actual time to wait for
something to happen. In case the machine is loaded heavily and other
processes contend for resources it may not get scheduled in time for
this to happen
This branch contains (now) a more sophisticated approach suggested
and demonstrated by pedronis.
Signed-off-by: Zygmunt Krynicki zygmunt.krynicki@canonical.com