[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: grpc transition





On Thu, Jun 13, 2024 at 4:57 PM Shengjing Zhu <zhsj@debian.org> wrote:
On Fri, Jun 14, 2024 at 4:50 AM Shengjing Zhu <zhsj@debian.org> wrote:
>
> On Wed, Jun 12, 2024 at 6:10 AM Reinhard Tartler <siretart@gmail.com> wrote:
> >
> > On Mon, Jun 10, 2024 at 8:19 AM Shengjing Zhu <zhsj@debian.org> wrote:
> >>
> >> On Mon, Jun 10, 2024 at 6:45 PM Reinhard Tartler <siretart@gmail.com> wrote:
> >> > On Mon, Jun 10, 2024 at 2:48 AM Shengjing Zhu <zhsj@debian.org> wrote:
> >> >> >> Though removing src:golang-github-golang-protobuf-1-3 probably will not be easy.
> >> >> >
> >> >> > Can you please elaborate on where you see the difficulties?
> >> >>
> >> >> Only pb.go files generated by protoc-gen-go-1-3 are compatible with
> >> >> gogo protobuf. That's where the protobuf transition stuck...
> >> >
> >> > Well, I suppose that means either protoc-gen-go-1-3 or protoc-gen-gogo (from gogoprotobuf).
> >> >
> >> > Can you please point out examples of packages with "pb.go" files that are generated with protoc-gen-go-1-3 and then used with gogo protobuf?
> >> >
> >>
> >> Hmm, I thought you already saw that. You mentioned
> >> https://github.com/containerd/ttrpc/issues/62#issuecomment-686768932
> >> in another thread.
> >> This is caused by using gogo protobuf (at runtime) with pb.go files
> >> (from golang-google-genproto-dev) generated by protoc-gen-go-1-5 (or
> >> newer).
> >
> >
> > Thanks for the reminder.
> >
> > I've started looking at ttrpc. This is an interesting package. Basically, they have implemented a "lightweight" grpc implementation, by replacing the framing mechanism to make it use less memory. That's cool. Their use of gogoproto is certainly problematic. Also, they provide a code generator that does not appear to be used by any package in Debian. I see no good coming from keeping this package in Debian, so I took the liberty of dropping that binary package. Please do let me know of any breakages, adding it back is easy and quick at this point.
> >
>
> The ttrpc generator is used by containerd to generate code, but
> currently due to lacking protobuild in Debian, this is not implemented
> in containerd packaging. But I see you start to package protobuild,
> the ttrpc generator could be kept.

Yupp, protobuild is currently in NEW: https://ftp-master.debian.org/new/protobuild_0.3.0-1.html

I needed it for the go-fix-acronyms hack that post-modifies the generated protobuf golang code.

https://salsa.debian.org/siretart/golang-github-containerd-cgroups/-/commit/83cae8e7d9b7fb78cedc4922c4395fe84d79e921

Next thing to work on: containerd

>

BTW despite the thread title is about grpc transition, we end up in
the trap of protobuf transition.
Since grpc-go has (finally!) switched golang-google-protobuf-dev in
recent version, I think we could decouple these two transition. I may
look at grpc-go this weekend.

Indeed, that appears to be the case in https://github.com/grpc/grpc-go/releases/tag/v1.64.0

let's see if we can get that into experimental, I think that's a great start.

BTW, since I didn't hear otherwise from you, it appears this ttrpc/grpc/containerd mess is the actual blocker for upgrading protobuf/grpc. Let's proceed with those upgrades in experimental and see that we end up with a working docker26 and podman. Then let's reconsider what's left to fix for uploading to unstable.

--
regards,
    Reinhard

Reply to: