-
Notifications
You must be signed in to change notification settings - Fork 114
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
Pass handles between nodes using Protocol Buffers #1108
Pass handles between nodes using Protocol Buffers #1108
Conversation
ef7e606
to
caa442b
Compare
I think this PR is ready for review now. Once we can agree on the code I will update the documentation to reflect the changes 😄. |
@tiziano88 would you mind reviewing this? |
Sure, I'll take a look next week. Could you rebase on master first, so that there are no unnecessary conflicts to resolve? Also, for vendoring prost, can you make sure there is an initial pristine commit, and then any subsequent changes are applied on top of that? |
aadc30e
to
16a4611
Compare
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.
Thanks @wildarch , this is looking great! And the changes seem very well contained, which I am sure must have taken a lot of attempts to get to this stage! Have a few comments, the main one related to visitor vs traversable / foldable as the main type for manipulating handles, then I'll take a closer look.
It's a shame that Cargo doesn't support (rust-lang/cargo#4648) applying a patch file to an existing repository (unlike Bazel); is it worth having a play with https://github.com/mettke/cargo-patch ? It might avoid us having to check in an entire copy of prost. (Alternatively, are the deltas to prost something that might be taken upstream eventually, or are they entirely Oak-specific? If the former, we could put the changes in a forked repo of prost and use the functionality that Cargo's built-in |
I wasn't aware of @tiziano88 and I did discuss a fork at some point, but apparently that would have to go through some kind of approval process? I'm not sure how this would work, @tiziano88 can you comment on this? I'm convinced that all the changes that we need to prost can be upstreamed in a more generalized form, I have a PR open to start this process (https://github.com/danburkert/prost/pull/317), but the crate author has not responded to it yet. |
2752257
to
daccc10
Compare
@tiziano88 I think there are some issues with dependency vetting to be resolved, other than that do you think this PR is in a good state to merge? |
As it's quite a large change (hint: next time perhaps try to make it smaller / more incremental if possible), I'd like someone else from the team to also review it. @daviddrysdale would you have time to do that? I will also take another closer look shortly. |
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.
Just a first pass so far, mostly focusing on the prost vendoring stuff.
114 / 136 files viewed
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.
Second pass and I'm starting to understand (and appreciate) what's going on – neat stuff!
123 / 136 files viewed
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.
136 / 136 files viewed
Sorry I'm being slow on this, I am planning to also take a closer look soon. |
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 have now looked more closely at the first few files, I expect this needs to be rebased on top of #1199 anyways?
examples/chat/proto/chat.proto
Outdated
|
||
message Command { | ||
oneof command { | ||
oak.handle.Sender join = 1 [(oak.handle.message_type) = ".oak.encap.GrpcResponse"]; |
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.
oak.handle.Sender join = 1 [(oak.handle.message_type) = ".oak.encap.GrpcResponse"]; | |
oak.handle.Sender join_room = 1 [(oak.handle.message_type) = ".oak.encap.GrpcResponse"]; |
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 think some extra comments would help to explain what's going on here, especially since there are not many other examples of Inter-Node Communication, so people will probably look at this one for reference.
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 have added more details here to all the protos, and split them into external gRPC and internal sections.
|
||
fn get_interface(&mut self) -> &BlobStoreInterface { | ||
// Make sure it is cached | ||
if let CachedStore::NotCached { sender, receiver } = &self.store { |
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.
Can this be moved into the match
below, and avoid the unreachable
?
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 tried to get this to work, but I'm not sure it's possible. The problem is that when I do
self.store = CachedStore::Cached(iface);
I can't also do a return &iface
, as iface
has already been moved. I also can't extract a reference through self.store
without doing a match somewhere, so I think this is the best we can get here. Do you have other ideas?
|
||
package oak.examples.injection; | ||
|
||
message BlobStoreInterface { |
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.
Isn't this the same (or very similar) as what we usually call "invocation" in the code?
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 think it is similar yes. But in this case the handles can be used to serve multiple requests, so I'm not sure we should call it an 'invocation'.
5f89e89
to
d3cb2ed
Compare
d3cb2ed
to
a5c02c2
Compare
3ff2cac
to
abcdab9
Compare
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.
Looks like there's some (minor) comments from my second pass that you haven't responded to – is GitHub's UI confusing things again?
// | ||
//! Example module showcasing handle passing inside of Protocol Buffers. | ||
//! | ||
//! The following diagram illustrates how the system stores client blobs: |
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.
Thanks, much clearer.
65b125f
to
d3bc5e0
Compare
Thanks David, it seems I did indeed miss a few comments. Hopefully I've now addressed all of them 😄 |
BUILD
Outdated
@@ -1,35 +0,0 @@ | |||
# |
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.
Is removing this file related?
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.
This should not have been removed, how I've managed to delete this is a mystery to me. Thanks for spotting it! 😄
sdk/rust/oak/src/handle.rs
Outdated
/// Order is significant: handles are injected starting at the first field, recursing | ||
/// into nested structs before moving on to the next field. |
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.
In order of field declaration, or of tag number? Perhaps add a test case that has fields in non-standard order (e.g. 3-1-2).
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.
In order of field declaration, handle extraction is not tied directly to protobuf types in any way (i.e. you can derive HandleVisit
for any type). I'll try and make this more clear in the comment, I'm not too sure we need such a test since the two are unrelated.
sdk/rust/oak/src/handle.rs
Outdated
/// If the number of handles provided is not exactly equal to the number of handles needed to fill | ||
/// the message, an error is returned. | ||
/// | ||
/// Order is significant: handles are injected starting at the first field, recursing |
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 guess this also means there is no backwards compatibility between different versions of the same message, right? i.e. adding a new field
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 is correct yes.
If we want this in future it might be possible, I'm unsure if our procedural macro could read the tag annotations meant for prost, though 🤔
d3bc5e0
to
e8a54ba
Compare
Not sure whether you can see CI results (#1112), but there's a few invalid doc links. Other than that, ready to merge I think!
|
Thanks @daviddrysdale, I saw them but wasn't able to reproduce them locally. Turns out I had some outdated docs in the I can reproduce the errors locally now so I should be able to address them, thanks! 😄 |
Also includes: - Custom derive macro to visit all handles in a struct/enum (crate oak_derive) - New example "injection" to showcase passing handles around.
e8a54ba
to
ef50128
Compare
@tiziano88 happy to merge? |
Sure, go ahead @daviddrysdale , thanks! And thanks @wildarch for all the work! |
Yay, awesome! 😃 🎉 Thanks for all the reviews guys 😄 |
Reproducibility Index:
Reproducibility Index diff: diff --git a/reproducibility_index b/reproducibility_index
index f55aea2..047e0b5 100644
--- a/reproducibility_index
+++ b/reproducibility_index
@@ -1,12 +1,13 @@
-27b563913abba69ab96699ca4576a5406231800739297d43f14647dfe28182d3 ./examples/target/wasm32-unknown-unknown/release/abitest_0_frontend.wasm
-aaa701e9c0fc58fd65e5956bf07dbc17a9fe30170d776f8c734e833ecc30718e ./examples/target/wasm32-unknown-unknown/release/abitest_1_backend.wasm
-4b88fc85c633e5413002b05ff66bec9ec653397f07f6799f889aeb7af14fb6e1 ./examples/target/wasm32-unknown-unknown/release/aggregator.wasm
-1e8c5a8ff13e83e228fa461eb049e7eb37600b980ef17e1e42aed2b9b14c8cc1 ./examples/target/wasm32-unknown-unknown/release/chat.wasm
-400c13da142185bb700bf6daaed1de58f38a6ebc98d52a67a0c93f425a806c77 ./examples/target/wasm32-unknown-unknown/release/database_proxy.wasm
-9035e13788e682a01e22c1ba42c125fccbfae4df296d7bd46318fb56044e19a2 ./examples/target/wasm32-unknown-unknown/release/hello_world.wasm
-c5646c404e5d4f4d354f1961e39bc9ca23989922741efee90b9f270625bdcd29 ./examples/target/wasm32-unknown-unknown/release/machine_learning.wasm
-3267614a8c860eef6449c40856cef55b04aceb95a206fe9d3cd70d2b3931d967 ./examples/target/wasm32-unknown-unknown/release/private_set_intersection.wasm
-656e89a34c1d964fd003e7421d204f96fd5c3853d27b142a9eec619f6f86f96b ./examples/target/wasm32-unknown-unknown/release/running_average.wasm
-aea5aa8876b8158f0d781665e089307e9de53b59104407e71422a58ed4cff6d2 ./examples/target/wasm32-unknown-unknown/release/translator.wasm
-080c53ca4491dbd9e279725cc32abddca83d0da14e645915981455b5b9f8ecd2 ./examples/target/wasm32-unknown-unknown/release/trusted_information_retrieval.wasm
+41e274c3757a74826f327ee287295854521fb9b232c69c3a8ce424f663d06bb8 ./examples/target/wasm32-unknown-unknown/release/abitest_0_frontend.wasm
+7cc210ce2abc06e438bf6b2fa760d8a971558a635ee4d453ce553f0336440c50 ./examples/target/wasm32-unknown-unknown/release/abitest_1_backend.wasm
+b1499033dc9c01664b60a81cf058b1f3796cfba19ef835619fa2dabd7cb4d21d ./examples/target/wasm32-unknown-unknown/release/aggregator.wasm
+d53a8d0506c38532648fc3ce442abb35ff170aee96d81c3f53cb96a000eaddb9 ./examples/target/wasm32-unknown-unknown/release/chat.wasm
+9d3fd950c5f27f5fe2484a62088de3c31b34a7e168c0156d140924f9c7fe426e ./examples/target/wasm32-unknown-unknown/release/database_proxy.wasm
+55115a2a0893a01587930ca9c074abb7023a8cdd1c3864e73e55474692e7fcd0 ./examples/target/wasm32-unknown-unknown/release/hello_world.wasm
+c3e02ae9ce838f488601f6536aa2c7ae5069db05426da530e0a5d29164af4d9a ./examples/target/wasm32-unknown-unknown/release/injection.wasm
+17299bcb7f0642ff6c5c3cec4366283fdc0430b2b9ccd5113762b66b3f425888 ./examples/target/wasm32-unknown-unknown/release/machine_learning.wasm
+25ceadbdcf66e9b7a8e1a1b096e5efabef0d4b9bd8060c62549e38e6f8e231a0 ./examples/target/wasm32-unknown-unknown/release/private_set_intersection.wasm
+bacd8942470cc84d379a88809f351f0d817d12a31a8608296c3743bd61ca3faa ./examples/target/wasm32-unknown-unknown/release/running_average.wasm
+ab4205f9351a85f7d201021530d5045da1f4e1682cf5c1c99caf604a4fa2c737 ./examples/target/wasm32-unknown-unknown/release/translator.wasm
+fa2598827a3b34a4cc16b31eb095c2f00862b0641c3e4e545f769a6d2fed1f68 ./examples/target/wasm32-unknown-unknown/release/trusted_information_retrieval.wasm
f7e04fec862016c4c4dfdb816062cd5227cf8325b3340e5cdbf7d29ff7d5a714 ./oak/server/target/x86_64-unknown-linux-musl/release/oak_loader
|
Checklist
Cloudbuild
cover any TODOs and/or unfinished work.
construction.
This is very much still a draft, but tests are passing (at least locally).
Todo:
Fixes #673.