01:04 <d_bot_> <mbacarella> what's the grpc story these days?

01:05 <d_bot_> <mbacarella> is proxying through envoy the least suffering involved solution still?

01:26 <sleepydog> it seems like grpc is possible, but not well paved yet. using some unmerged PRs to ocaml-protoc-plugin

02:11 <companion_cube> oh?

08:17 <d_bot_> <quernd> It may be the easiest but note that the Envoy setup doesn't allow streaming. It's possible in pure OCaml though. We've been using this fork of jeffa5's `ocaml-grpc`: https://github.com/dialohq/ocaml-grpc/tree/bugfixes for both server and client bidirectional streaming and so far it's working out well. The `ocaml-protoc-plugin` changes are not strictly necessary, it's a quality of life enhancement.

15:12 <d_bot_> <mbacarella> seems workable. is there an analog to secure_channel? https://grpc.github.io/grpc/python/grpc.html#grpc.secure_channel

16:31 <d_bot_> <quernd> You can use `H2_lwt_unix.Client.TLS` or `SSL` to create a secure connection, if that's what you mean.

16:34 <d_bot_> <mbacarella> i'm not really sure what i mean. grpc is pretty mystifying to me still

16:34 <d_bot_> <quernd> Typically, you'd create one connection and keep it open to do all the RPC requests over it

16:35 <d_bot_> <mbacarella> will try it though

16:36 <d_bot_> <Anurag> Is GRPC mandatory for your project? You might want to start with a simpler rpc option 🙃

16:39 <d_bot_> <mbacarella> sadly yes

16:39 <d_bot_> <mbacarella> i would very much like to not be using grpc

16:39 <d_bot_> <Anurag> 😅 Goodluck!

16:40 <d_bot_> <quernd> Good luck, shout if you run into issues 🙂

16:40 <d_bot_> <mbacarella> > INTERNAL_ERROR (0x2), Failure("Tls not available")

16:40 <d_bot_> <mbacarella> I assume I need to opam install tls

16:43 <d_bot_> <Anurag> I believe so. I think the error originates in the underlying `gluten` library that probes the system to check whether `ocaml-tls` is installed or not, and fails if you attempt to use the tls transport without installing ocaml-tls

16:43 <sleepydog> I don't know what a secure_channel is. It doesn't seem to be part of GRPC, but rather a name chosen for the python api

16:44 <sleepydog> http/2 all but requires TLS, so every "channel" (I assume that refers to an http2 stream) should be secure

16:47 <d_bot_> <quernd> "channel" is more like a connection, not a stream

16:48 <sleepydog> ah, ok. and i guess i was wrong about http2 requiring encryption. sorry for the confusion

16:49 <d_bot_> <quernd> It's not required, but browsers enforce it, apparently

17:02 <d_bot_> <mbacarella> hmm, when i try Client.TLS instead of just Client instead of getting a read error it just hangs

17:02 <d_bot_> <mbacarella> tcpdump does show a connection opens

17:06 <sleepydog> is there an ssl handshake?

17:06 <d_bot_> <mbacarella> there is back and forth

17:07 <d_bot_> <mbacarella> might be time for mitmproxy

17:14 <d_bot_> <mbacarella> oh maybe i shouldn't use ~error_handler:ignore

17:14 <d_bot_> <mbacarella> protocol error: PROTOCOL_ERROR (0x1),

17:14 <d_bot_> <mbacarella> there we go

17:14 <sleepydog> :)

17:18 <d_bot_> <quernd> That one is very unspecific, unfortunately. I ran into it e.g. when my headers weren't all lowercase

17:22 <d_bot_> <mbacarella> am i wrong to be mad at google here

17:23 <d_bot_> <mbacarella> anyway. guess i'll have another coffee and start adding prints up and down the stack

17:24 <sleepydog> mad over GRPC? or are you talking to a googleapi

17:24 <d_bot_> <mbacarella> mad that they kinda threw their weight behind pushing grpc

17:25 <d_bot_> <mbacarella> but also coupled it with h2

17:25 <sleepydog> i work at google and just resolved a weeks-long customer issue that ended up being caused by contention over the 1 connection Go's GRPC client uses by default. so i'm mad at google too :)

17:27 <d_bot_> <mbacarella> right. also go 😠

17:27 <d_bot_> <quernd> My guess is it's wrong/missing headers but that's just from experience.

17:28 <sleepydog> i think it was a mistake to push a stubby-like protocol without also bringing along its transport (quic)

17:30 <d_bot_> <mbacarella> yeah, fortunately i have a python implementation that works that i can run through mitm proxy and will compare what the ocaml one is doing

17:30 <d_bot_> <mbacarella> just, you know, caffeine

17:31 <d_bot_> <mbacarella> thanks for the hand-holding. together we'll defeat grpc

18:06 <d_bot_> <quernd> Just to elaborate on my previous remark about headers, I have this minimal example of a secure call to grpc-test.sandbox.googleapis.com:443 where it fails with this non-descript `PROTOCOL_ERROR (0x1)` as soon as I leave out a required header or use uppercase. Case in point, for the Google test API you need the `:authority"` header even though generally it's optional

20:07 <companion_cube> I've never used it, but twirp seems a lot more reasonable

20:07 <companion_cube> just need to modify ocaml-protoc to produce it :p

20:20 <d_bot_> <anmonteiro> Just to add here that the h2 API is fairly lowlevel and expects you to do the right thing. If the right thing is not obvious open an issue and I’ll see what we can improve

20:23 <d_bot_> <quernd> Not blaming h2 at all for this, that would be shooting the messenger 😉

20:25 <companion_cube> isn't also grpc this thing google does NOT use internally

21:43 <d_bot_> <mbacarella> it was giving me protocol error 0x1 because i ***obviously*** forgot to include the header content-type: application/grpc

21:44 <d_bot_> <mbacarella> *headdesk*

21:44 <d_bot_> <mbacarella> only had to man-in-the-middle-attack this grpc service to figure it out

23:41 <d_bot_> <ansiwen> do you think that could work as an etcd client?

23:50 <d_bot_> <ansiwen> I created a rest api client for the gRPC gateway of etcd, but if a native gRPC access is feasible, I might prefer that.