The api/internal routes need to not be proxied to allow detection if
the repository exists locally for a project, and redirection to the
primary if not.
The geo/proxy_git_ssh route is used internally by gitlab-shell to
then proxy the git+ssh operations to the primary, using the internal
URL of the primary (hence why these don't get proxied and is intended
that they hit the secondary).
Changelog: changed
EE: true
Gitlab Rails doesn't have endpoints that require uploading
multiple files.
Let's limit it to prevent performance issues and proceed with
a proper solution out of Security Release
Changelog: security
As the secondary is read-only, we want to ensure pushes are proxied
to the primary, while reads are served localy, same with LFS files.
Changelog: changed
EE: true
zipartifacts uses a http-client based ReaderAt implementation that fetches parts of a remote zip
file by using Range headers. We don't have direct control of the ranges that will be requested, so
this test ensures that changes to the underlying zip reader won't negatively affect performance by
making more range requests than expected.
When the Geo Rails API intends to disable the proxying functionality,
like for example not being a secondary anymore, or the Rails feature
flag is disabled, an empty URL will be returned.
This prevents the empty, invalid URL from getting parsed and resulting
in panics because of it.
Changelog: changed
EE: true
With this change, we measure durations in Prometheus
(in `imageResizeDurations`) whenever the requested image has not been modified and hence the cached version can be used by the client.
In this case, the image resizer process is not invoked, but
the client gets to see the image anyway.
As apdex is a measure of user satisfaction, it should not matter “where does the image come from?”, rather it should only care about “how soon is the image served”, which is why we have now decided toinclude the measurement of “cached versions” delivery in this apdex.
Changelog: changed
In order to support proxying from a secondary to a primary,
while the authentication can still happen on both sites,
we need to have two different paths so that the secondary-specific
path can be excluded from proxying.
Changelog: changed
EE: true
When Gitaly makes internal API calls back to Workhorse in Git hooks,
Workhorse previously would generate new correlation IDs, making it hard
to trace the entire call flow.
In https://gitlab.com/gitlab-org/labkit/-/merge_requests/123, we added
the ability to propagate correlation IDs from trusted CIDR blocks.
To use this feature, we add two configuraton parameters:
* `trusted_cidrs_for_x_forwarded_for`
* `trusted_cidrs_for_propagation`
If propagation of correlation ID is enabled,
`trusted_cidrs_for_x_forwarded_for` tells LabKit what remote IPs can be
trusted to use the `X-Forwarded-For` HTTP header to resolve the actual
client IP. Note that this parameter is not yet used in Workhorse's
remote IP resolution, but it should be.
`trusted_cidrs_for_propagation` allows Workhorse to restrict propagation
to certain IP ranges. We will want to add the Gitaly servers to this
list.
Relates to https://gitlab.com/gitlab-org/gitlab/-/issues/324836
Changelog: added
By default, a Geo proxy will proxy all requests to the URL returned by
the API endpoint `/api/v4/geo/proxy`.
Certain routes, defined in `GeoLocalRoutes`, can be served locally for
improved performance. Many more local routes will be added later.
