Skip to content

How and when to deprecate PostUploadPack

In &463 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.

  1. Is this something we need to worry about?
  2. 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, we will move forward by enabling the workhorse_use_sidechannel feature flag by default, and eventually removing it.

Edited by Jacob Vosmaer