Deprecate gRPC proxies between gitaly and the rest of GitLab
For guidance on the overall deprecations, removals and breaking changes workflow, please visit https://about.gitlab.com/handbook/product/gitlab-the-product/#breaking-changes-deprecations-and-removing-features
Deprecation Summary
Although not recommended or documented, it used to be
technically possible to deploy a gRPC-aware proxy between Gitaly and
the rest of GitLab. Examples of gRPC-aware proxies are NGINX and
Envoy. If self-managed instances currently use a gRPC-aware proxy for
Gitaly connections they should change their proxy configuration to use
TCP or TLS proxying (OSI Layer 4) instead.
Note that Gitaly Cluster has been incompatible with gRPC-aware
proxies since GitLab 13.12. What changes is that _all_
installations are now incompatible with gRPC-aware proxies, even
without Gitaly Cluster.
The reasons for this change are outlined in [this
epic](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/463). By
sending some of our internal RPC traffic through a custom protocol we
increased throughput and reduced Go garbage collection latency.Breaking Change
Yes. Users should remove the gRPC proxy between gitaly and the rest of GitLab, or reconfigure the proxy to work on the level of TCP/TLS sessions instead of gRPC requests.
Affected Topology
Self-managed
Affected Tier
All.
Checklist
-
@mention your stage's stable counterparts on this issue. For example, Customer Support, Customer Success (Technical Account Manager), Product Marketing Manager. - To see who the stable counterparts are for a product team visit product categories
- If there is no stable counterpart listed for Sales/CS please mention
@timtams - If there is no stable counterpart listed for Support please @mention
@gitlab-com/support/managers - If there is no stable counterpart listed for Marketing please mention
@cfoster3
- If there is no stable counterpart listed for Sales/CS please mention
- To see who the stable counterparts are for a product team visit product categories
-
@mention your GPM so that they are aware of planned deprecations. The goal is to have reviews happen at least two releases before the final removal of the feature or introduction of a breaking change.