Skip to content
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

Merged
merged 2 commits into from
Feb 3, 2024
Merged

Move Message proto to types #9742

merged 2 commits into from
Feb 3, 2024

Conversation

mxpv
Copy link
Member

@mxpv mxpv commented Feb 2, 2024

We currently duplicate Envelope proto in several places and I need another one for #9704.
This PR moves Envelope struct to types/, so we can reuse it.

Moving proto messages expected to be backward compatible as long as we preserve memory layout (which we do).

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;
Copy link
Member

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?

Copy link
Member Author

@mxpv mxpv Feb 2, 2024

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;
Copy link
Member

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?

Copy link
Member Author

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.

@samuelkarp samuelkarp added this pull request to the merge queue Feb 3, 2024
Merged via the queue into containerd:main with commit 96bf529 Feb 3, 2024
46 checks passed
@mxpv mxpv deleted the envelope branch February 3, 2024 07:38
@fuweid
Copy link
Member

fuweid commented Feb 3, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants