Migrate away from gogo

[AndreasBergmeier6176]

Since gogo/protobuf is no longer maintained it might make sense to start migrating away from it.

See gogo/googleapis#19 (comment)

[crazy-max]

I took a look in the past to migrate away from gogo/protobuf but any alternative might break the contract unfortunately.

Links

• https://go.dev/blog/protobuf-apiv2
• Migrate away from gogo/protobuf TheThingsNetwork/lorawan-stack#2798
• Migrating from gogo/protobuf to Google's offical protobuf package firecracker-microvm/firecracker-containerd#452
• https://jbrandhorst.com/post/gogoproto/
• https://vitess.io/blog/2021-06-03-a-new-protobuf-generator-for-go/
• https://github.com/alta/protopatch
• Discussion about future gRPC support in v2: [golang/protobuf#1070](plugins are not supported : grpc golang/protobuf#1070)
• Explore using vtprotobuf etcd-io/etcd#13107
• Migrate away from gogoprotobuf to protobuf v2 API + vtprotobuf thanos-io/thanos#4557
• Implement a new code generator that doesn't use gogo/protobuf containerd/ttrpc#92
• Use google.golang.org/protobuf instead of github.com/gogo/protobuf containerd/cgroups#220

Alternatives

• https://github.com/planetscale/vtprotobuf

vtprotobuf migrations in the wild

• https://giedrius.blog/2022/02/04/things-learned-from-trying-to-migrate-to-protobuf-v2-api-from-gogoprotobuf-so-far/
• https://github.com/rahulii/thanos/pull/1/files?file-filters[]=.proto&show-viewed-files=true

[jedevc]

Since this would likely be such a breaking change, I wonder if we should save this for if/when we hit buildkit 1.0? Without a breaking change, we'd need to support both the old protobuf and the protobuf for a few versions, and somehow determine between them, which sounds messy.

[AkihiroSuda]

I heard of another alternative: https://github.com/CrowdStrike/csproto
They have a migration guide from gogo: https://github.com/CrowdStrike/csproto/blob/main/docs/migration_guide.md

@tonistiigi What should we do?

[tonistiigi]

Are the alternatives compatible on the wire? If not then this will be tricky and if we ever change we should reevaluate the whole grpc story. If compatibility is maintained then I don't have any desire to keep gogo. Compatibility on Go API level is not important.

[AkihiroSuda]

https://github.com/CrowdStrike/csproto/blob/main/docs/migration_guide.md says "csproto is designed to, as mush as possible, be a drop-in replacement"

[crazy-max]

https://github.com/CrowdStrike/csproto/blob/main/docs/migration_guide.md says "csproto is designed to, as mush as possible, be a drop-in replacement"

Unfortunately, if you are currently using the more advanced code generation enabled by protoc-gen-gogofast, protoc-gen-gogofaster, or protoc-gen-gogoslick then you will lose functionality as the new protoc-gen-go plug-in does not provide the same features.

buildkit/cache/contenthash/generate.go

Line 3 in 4410c82

//go:generate protoc -I=. -I=../../vendor/ --gogofaster_out=. checksum.proto

buildkit/solver/pb/generate.go

Line 3 in 4410c82

//go:generate protoc -I=. -I=../../vendor/ --gogofaster_out=. ops.proto

https://github.com/moby/buildkit/search?q=gogoslick

[marxarelli]

I came across this issue while hacking locally to see if I could get buildkit working with xds (specifically I wanted to get it working with Istio's Envoy based service mesh). Long story but the part that's relevant here is that I got quite far but in the end I couldn't get the generated code to properly use the grpc.ServiceRegistrar interface over a *grpc.Server. This seems to be a limitation of the out of date (and FWICT unmaintained?) gogo protoc and its grpc plugin.