-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
Move Message proto to types #9742
Conversation
Signed-off-by: Maksym Pavlenko <pavlenko.maksym@gmail.com>
Signed-off-by: Maksym Pavlenko <pavlenko.maksym@gmail.com>
@@ -55,17 +54,9 @@ message PublishRequest { | |||
} | |||
|
|||
message ForwardRequest { | |||
Envelope envelope = 1; | |||
containerd.types.Envelope envelope = 1; |
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 to confirm, since the structure is the same, the bytes on the wire should be the same. The protobuf type name changing won't have any impact on deserialization between v1 and v2?
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.
Message names aren't typically sent on the network (Any
is an exception, but we don't use it here), protobuf cares about message fields types/numbers to be compatible.
I googled a few confirmations just to be sure:
option go_package = "github.com/containerd/containerd/v2/api/types;types"; | ||
|
||
message Envelope { | ||
option (containerd.types.fieldpath) = true; |
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.
Do we not need the go-fieldpath generator for this?
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.
Doesn't look like it's used anywhere in the codebase.
Though the old versions had the field code generated.
If possible, it should have upgrade test for this. I don't worry about CRI. just want to confirm there is no regression for docker engine. |
We currently duplicate
Envelope
proto in several places and I need another one for #9704.This PR moves
Envelope
struct totypes/
, so we can reuse it.Moving proto messages expected to be backward compatible as long as we preserve memory layout (which we do).