-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
remote: make the dynamic spawn scheduler work. Fixes #8646 #8648
Conversation
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.
Oh, is it that simple?
Other than failing CI, LGTM :)
@@ -304,6 +304,10 @@ private SpawnResult downloadAndFinalizeSpawnResult( | |||
SpawnExecutionContext context, | |||
RemoteOutputsMode remoteOutputsMode) | |||
throws ExecException, IOException, InterruptedException { | |||
// Ensure that when using dynamic spawn strategy that we are the only ones writing to the |
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.
Reword: "Ensure that we are the only ones writing to the output files when using the dynamic spawn strategy."
Also not sure why the bug link in the code is necessary. Yes, there was a bug that's fixed with this change. Reference it in the commit description instead?
This change fixes the correctness issue of dynamic spawn scheduler when being used with remote execution. See bazelbuild#8646 for more details. There's a performance issue remaining: bazelbuild#8467
between RemoteSpawnRunnerTest and GrpcRemoteExecutionClientTest.
f642b98
to
4399f02
Compare
I updated the code to also include the .tmp download optimization. ptal. |
Do you mean #8647 or something else? |
yes #8647 |
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.
Please change the commit message/PR description that #8647 is also addressed here.
Do we have integration tests for dynamic strategy?
I ll update the commit message when importing. I split it out into three commits for easy review :).
I am quite sure we don't. It seems hard to test in an integration test? |
thanks! :)
well, maybe it is hard to test details (like whether the files were downloaded to the temp directory and then moved, racing conditions), but we can still have test for a base case, to make sure that it works, i.e. not failing and outputs in the end are in the right place. |
how would one do that with reliably triggering the dynamic spawn strategy? |
simple action with --remote_executor pointing to a RemoteWorker and enabled dynamic spawn strategy |
this does not trigger the dynamic spawn strategy. it will just trigger the remote spawn strategy. |
then how do we know that it didn't work before your fix in the first place? |
user reports and manual testing :\ |
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.
Agreed that the simple integration test will be added as a separate change ;)
LGTM
This change fixes the correctness issue of dynamic spawn scheduler when being used with remote execution. See bazelbuild#8646 for more details. There's a performance issue remaining: bazelbuild#8647 Closes bazelbuild#8648. PiperOrigin-RevId: 253998300
This change fixes the correctness issue of dynamic spawn scheduler when being used with remote execution. See bazelbuild#8646 for more details. There's a performance issue remaining: bazelbuild#8647 Closes bazelbuild#8648. PiperOrigin-RevId: 253998300
This change fixes the correctness issue of dynamic spawn scheduler when being used with remote execution. See #8646 for more details.
There's a performance issue remaining: #8647