-
Notifications
You must be signed in to change notification settings - Fork 240
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
Add build info across all requests #502
Add build info across all requests #502
Conversation
Hi @vaskomitanov! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks! |
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks! |
There is already a type defined by RBE for this, which #310 sends. You could pick up that PR and add the config flag that was requested. |
Yes, sorry for not getting around to it lately. I think #310 is the right way forward, but note that PR is very incomplete. Most of the plumbing for the RBEv2 metadata isn't there, so I think a lot of refactorings need to go in, first. |
#310 looks exactly what I needed, thanks for starting this effort @thoughtpolice. I will rebase my changes of yours and use the |
c05ebb0
to
9950c18
Compare
@vaskomitanov - are all your rebasings done now? |
31ebaaf
to
dbfcc1c
Compare
Yes. There are few fields not yet populated but even in this state we have all of the needed information for efficient scheduling for action execution and caching. |
Thanks for taking this over the finish line! Please note that @krallin did I have one important adjustment he wanted me to make in #310 (comment)
That is, they do a build of the OSS version of Buck internally and test that. So, we need to refactor this part of the diff in particular to just use a 2eaa19c#diff-0bb786b03f4f35aef10055270239e2afbf4f4b0ba0fa214b38ffa858c4bc9e95R1257-R1323 Maybe we should call it:
And then default it to |
fde1407
to
7205dcd
Compare
OK, sorry for the wait (thanksgiving), I've made requested changes. |
THIS IS A SAMPLE COMMENT |
IMO it should be turned off by default; after all, the code path in question is located inside the RPC client for the OSS Bazel API, so it's the exact path all OSS users rely on. This codepath should work as expected in OSS builds, i.e. with OSS metadata. We could |
OK, done, default is "false" |
121f713
to
35f08e8
Compare
@ndmitchell any additional steps I need to do to get this PR merged? |
Sorry for the delay - was travelling then got a bit ill. Just running through the code now. |
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.
Sorry that this took so long to get to. Overall this looks right, just a couple of thoughts
app/buck2_execute/src/re/uploader.rs
Outdated
let mut mtd = use_case.metadata(); | ||
if let Some(identity) = identity { | ||
apply_identity(identity, &mut mtd); | ||
} |
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.
Hm, so I'm not the expert on this code, but I'm not super clear on the difference between the cases where this is applied vs the cases where it isn't? Is there a reason that some of these are more important than others?
I would've expected the Option<&ReActionIdentity>
to instead become a mandatory parameter to use_case.metadata()
, so that call sites have to explicit ask for the None
behavior instead of letting this go forgotten
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.
Great question!
This PR covers the RE GRPC request sequence: find missing blobs
-> upload missing blobs
-> execute action
-> download produced artifacts
.
This way on the server side we can be smart when replicating CAS artifacts and dispatching actions (we will be able to correlateaction execution
with preceeding artifact uploads
).
Without this change we are simply receiving 100s of parallel find missing blobs
requests, 100s of parallel upload missing blobs
and execute action
without any correlation between them (even though they are correlated).
Other cases are not covered (can be covered in the future) because a) are not relevant regarding replication or request dispatching, b) will unnecessarily increase the grpc requests payload (in the header section).
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.
Other cases are not covered (can be covered in the future) because a) are not relevant regarding replication or request dispatching
Leaving things not completely finished in this PR is fine, but just for clarity: What are the other cases? I guess I see action cache fetches and maybe cas_artifact
actions. Anything I'm missing?
will unnecessarily increase the grpc requests payload (in the header section).
I think even (and maybe especially) if this is intentionally not being filled out in some cases we should make that explicit in the code by requiring the parameter on use_case.metadata()
and then writing a comment to explain why we pass None
in some cases. Otherwise this will be forgotten about in the future
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.
That makes sense. I’ve updated the code to address this concern.
Summary: When doing requests to a RBE service, it's useful to attach the 'RequestMetadata' type defined by Bazel onto gRPC requests, using a specific header. This is actually already done, more or less, but only for the internal fbcode build service which uses a different and simpler Metadata structure, and a different header. Therefore attaching a new header isn't so complicated. This also ensures that non-fbcode builds of Buck2 don't bother attaching fbcode Metadata, since it's not useful and can only be tested internally there, anyway. And likewise, we don't attach OSS Bazel RequestMetadata to fbcode_build configurations, either. Test Plan: NIH. Signed-off-by: Austin Seipp <aseipp@pobox.com> Change-Id: Irrsqpmptqmzzoukzuzrqmkxsoqtxvuvx
35f08e8
to
ba485da
Compare
ba485da
to
0122a0f
Compare
@JakobDegen has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
This pull request has been reverted by 1d39ef8. |
The label was technically right that this was reverted, but I relanded it a day later so all good :) |
No description provided.