How and when to deprecate PostUploadPack
In &463 (closed) we are creating a replacement for the Gitaly PostUploadPack RPC called PostUploadPackWithSidechannel. That means GitLab should stop using PostUploadPack.
PostUploadPack is a normal gRPC RPC. PostUploadPackWithSidechannel only works if the gRPC connection is encapsulated in the Gitaly-specific "backchannel" network protocol. This presents a possible obstacle. If self-managed installations have a gRPC proxy between Workhorse and Gitaly for whatever reason, then that proxy would reject the backchannel connections.
- Is this something we need to worry about?
- If so, what do we do about it?
Conclusion
The benefits of the new protocol are so great that everyone should be using it. It makes no sense to long-term support not using the protocol.
If anybody runs into trouble because their self-managed infrastructure does not allow the new protocol through then the solution is to modify their infrastructure: either bypass the proxy, or configure the proxy to work at the level of TCP connections (OSI layer 4).
Within the scope of &463 (closed), we will move forward by enabling the workhorse_use_sidechannel feature flag by default, and eventually removing it.