-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Migrate off of gogo/protobuf #4422
base: master
Are you sure you want to change the base?
Conversation
b518a14
to
f81a7cc
Compare
The fsutil change is in tonistiigi/fsutil#171. |
c5ad2bd
to
2979fbf
Compare
Is there a guarantee that this does not break old-new client-daemon combinations? |
Yes. gogo/protobuf didn't modify the wire protocol. Their changes are primarily around code generators to make it more Go-idiomatic and efficient. I did a similar refactorting for containerd (see containerd/containerd#6564), and it has been released as containerd 1.7.0. We haven't heard any complaints regarding the compatibility. |
2ba5d69
to
f4aa840
Compare
Seeing some test failures; are those expected?
|
No. It should be fixed in the last revision, but the PR is still work-in-progress... |
0dead12
to
d50b3b1
Compare
By fixing all golangci-lint errors, I ended up getting |
ff8e07b
to
d7e32bb
Compare
|
||
message WorkerRecord { | ||
string ID = 1; | ||
map<string, string> Labels = 2; | ||
repeated pb.Platform platforms = 3 [(gogoproto.nullable) = false]; | ||
repeated pb.Platform platforms = 3; |
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.
Could we get some backward compatibility proving unit tests for the structs where the proto definition changed? Tests that use binary assets generated from previous version.
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.
Let me check. I could write a few, but probably not for all of them. I feel that it is more like testing protos, not Buildkit.
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.
It may make sense to do that in master first since this PR changes protos :)
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.
Opened #4570.
util/proto.go
Outdated
@@ -0,0 +1,79 @@ | |||
package util |
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 shouldn't be generic util pkg. Maybe util/cast
?
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.
Sounds good.
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.
Addressed by fc4c2fe
@@ -51,11 +50,11 @@ func New(ctx context.Context, opts map[string]string, session, product string, c | |||
} | |||
|
|||
if resp.FrontendAPICaps == nil { | |||
resp.FrontendAPICaps = defaultCaps() | |||
resp.FrontendAPICaps = util.PointerSlice(defaultCaps()) |
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.
If it doesn't change anything else we should consider changing definition of defaultCaps()
etc in these cases instead of converting.
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.
Yeah. I was doing these conversions to change stuff incrementally. Let me check whether I can move that to the original functions instead of converting.
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 PointerSlice and some other type-casting functions are gone at fc4c2fe.
Are there any updates on the progress here? The only reason I care is that #4455 is accidentally dependent on it (see the PR description for why). I totally get this PR may take some more time+effort to finish up, but if it's going to take a significantly longer time then it may be worth considering whether we should revert the changes in fsutil and have this PR depend on a fork of fsutil until it's ready to merge. Otherwise we'll be stuck in this state of not being able to update fsutil for a while. cc @kzys (hi! long time no see 😄) @tonistiigi |
Hi again @sipsma! Sorry, I was blocking the review. Let me update the PR shortly.
@tonistiigi - Do you have benchmarks for Buildkit itself? |
…obuf Signed-off-by: Kazuyoshi Kato <kato.kazuyoshi@gmail.com>
gogo/protobuf has been deprecated since 2022. This change uses Google's official code generators instead of gogo's. Signed-off-by: Kazuyoshi Kato <kato.kazuyoshi@gmail.com>
With gogo, all protobuf-generated structs had Size() methods, and Size field was renamed to Size_ to avoid conflicts. With google.golang.org/protobuf, the structs simply have Size fields. Signed-off-by: Kazuyoshi Kato <kato.kazuyoshi@gmail.com>
Signed-off-by: Kazuyoshi Kato <kato.kazuyoshi@gmail.com>
In google.golang.org/protobuf, an empty message and nil are interchangeable. golang/protobuf#965 Signed-off-by: Kazuyoshi Kato <kato.kazuyoshi@gmail.com>
Signed-off-by: Kazuyoshi Kato <kato.kazuyoshi@gmail.com>
google.golang.org/protobuf made all proto structs with a mutex to prevent copies. Signed-off-by: Kazuyoshi Kato <kato.kazuyoshi@gmail.com>
Signed-off-by: Kazuyoshi Kato <kato.kazuyoshi@gmail.com>
These serialized binaries can be used to test changes like moby#4422. Signed-off-by: Kazuyoshi Kato <kato.kazuyoshi@gmail.com>
These serialized binaries can be used to test changes like moby#4422. Signed-off-by: Kazuyoshi Kato <kato.kazuyoshi@gmail.com>
These serialized binaries can be used to test changes like moby#4422. Signed-off-by: Kazuyoshi Kato <kato.kazuyoshi@gmail.com>
These serialized binaries can be used to test changes like moby#4422. Signed-off-by: Kazuyoshi Kato <kato.kazuyoshi@gmail.com>
These serialized binaries can be used to test changes like moby#4422. Signed-off-by: Kazuyoshi Kato <kato.kazuyoshi@gmail.com>
These serialized binaries can be used to test changes like moby#4422. Signed-off-by: Kazuyoshi Kato <kato.kazuyoshi@gmail.com>
I think for this we would do micro-benchmarks for marshaling, unmarshal. If we start running containers then this would skew the timing too much. In fsutil there was also a benchmark script that maybe can be used. Maybe LLB marshal and load is a nice candidate. The biggest possible performance issue would be with the session endpoint and the context and build result transfer. This is where 100s of MB can potentially be transferred and encoded/decoded. If session uses gRPC dialer then it also uses protobuf for raw data framing. I believe previously some of these decoding could avoid allocating more memory because the |
Just wondering, coz of the movements in the codebase, we are bound to have a lot of merge conflict as we go. Is possible to split this into some self-contained chunks like perhaps sub-packages and chain the PRs? |
gogo/protobuf has been deprecated since 2022. This PR uses Google's official code generators instead of gogo's.
Fixes #3119