Generate GRPC contracts for runtime APIs#7979
Conversation
|
/test pull-containerd-sandboxed-node-e2e |
kzys
left a comment
kzys
left a comment
There was a problem hiding this comment.
Wow. It works without Protobuild changes 😎
|
Just curiosity about task/v3 memory cost. I remember that ttrpc is used to reduce memory usage in shim level. So is it going to use grpc in runc shim in the following release? Thanks |
|
@fuweid This shouldn't change anything about existing shims. This doesn't have any client changes yet, but I would think we need a way to either negotiate the protocol or configure it. It could be easy to negotiate just through file naming, socket name or shim naming scheme. |
It is kind of API-level changes.
Yes. Before migrate into task/v3, I think we should provide the memory cost report on this. |
mxpv
force-pushed
the
grpc
branch
3 times, most recently
from
62ecad0 to
e3e8dbc
Compare
Signed-off-by: Maksym Pavlenko <[email protected]>
Signed-off-by: Maksym Pavlenko <[email protected]>
Signed-off-by: Maksym Pavlenko <[email protected]>
|
/test pull-containerd-sandboxed-node-e2e |
|
@mxpv I'm just curious that what kind of the non-Go/Rust shims is. 😂 |
|
@Burning1020 as an example of such use case: On MacOS you'd want to use ObjC or Swift to interact with OS frameworks (like Virtualization framework). Both Go and Rust would need some sort of wrapper to be maintained. |
|
how about create a new plugin in containerd,the containerd plugin trans grpc to ttrpc to connect shim (if shim use ttrpc )we don't need let goshim support grpc server, I afraid it use more memory. @mxpv |
8 participants
We'd like to introduce GRPC based shims as experimental features in 1.7.
There were a few attempts before, original issue and motivation discussed here: #2399
Primarily this aims to unblock non-Go/Rust shims implementations.
This PR is step 1 - it adds generated GRPC code to addition to TTRPC.
It shamelessly steals Derek's approach from #7609 to generate TTRPC and GRPC code in one package.
For sandbox API we just generate both TTRPC and GRPC code in one package (TTRPC based contracts now get
TTRPCprefix). We can do that because we don't care about backward compatibility as we haven't introduced this API publicly.For Task service, in order to keep backward compatibility in 1.7, I add another temporary packagetask_grpcnext totask. It reuses structures, but dups service proto. We'll consolidate these in one package in 2.0.For task service, to keep backward compatibility, this PR introduces
task/v3, which includes TTRPC contracts (withTTRPCprefix) along with GRPC code.