**Status**: It is currently already possible to use [Geo with a single, location aware URL](https://docs.gitlab.com/ee/administration/geo/replication/location_aware_git_url.html). This is not yet possible for the WebUI. ### Summary (for the Release Post, future state) When configuring your local git installation, all GitLab instances, including the **primary** and all **secondary** nodes, can be reached using the same URL. There is no configuration change needed to select the closest Geo node - GitLab selects the best node automatically. We also redirect all WebUI requests to the **primary* instance. The **secondary** WebUIs will only be used for disaster recovery purposes. This means users will only need to work with a single URL for the WebUI. ### Context <!-- What is the situation? What is the complication? --> GitLab Geo installations contain at least one `primary` and one `secondary` node. Currently, both nodes can be accessed by users using two separate URLs e.g `https://us.example.com` and `https://eu.example.com`. This means that a systems administrator will need to maintain a list of URLs and that the "best" Geo node needs to be communicated to users. Users will then need to a) navigate to the Geo UI using the URL and users will need to setup git to clone and pull from the separate Geo URL. This is viable for small Geo installations with one `secondary`; however, the administrative load increases with the number of additional `secondaries`. [Systems administrators](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) will need to communicate to [software developers](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) which node is the "best" for them to use. In many cases, the "best" node may be the closest in terms of locations but there may be other considerations. ### Our intent <!-- What is it that we want to achieve? What is it you really, really want? --> We want to reduce the administrative burden for [systems administrators](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) so that they do not need to configure and communicate the right `secondary` URL to [software developers](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer). We want our users to automatically use the Geo node with the best user experience without having to change their git configurations or remember URLs. Systems administrators should not have to configure services separately depending on where they are located and having to add specific URLs to their services e.g. Jenkins. We also want our users not to have to understand the specific implementation details of Geo - the user experience should be similar independent of where users are located. ### Higher intent <!-- How does this epic fit into the product category and the wider GitLab strategy? --> GitLab should pick sane default values for our users. In the case of Geo, we consider improved user experience and reduced administrative burden as key components to increase the category maturity from `minimal` to `viable`. (Include link to category page) ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas can be found at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ --> * [Systems administrators](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) * [Software developers](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> We already support [multiple secondary sites behind a load balancer](https://docs.gitlab.com/ee/user/admin_area/geo_nodes.html#multiple-secondary-sites-behind-a-load-balancer). This can limit the number of URLs to maintain. ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey -->  We will this epic into two distinct parts that can be iterated on independently: 1. **Fully transparent git configuration for Geo** Further discussed in https://gitlab.com/groups/gitlab-org/-/epics/2038 2. **Improved Web UI user experience for Geo** This is the more uncertain part of the epic and could render other epics (e.g. https://gitlab.com/groups/gitlab-org/-/epics/1528) obsolete. We propose that instead of maintaining several individual Web UIs (one for each `secondary` in read-only mode and one for the `primary` in read-write mode), all users independent of their location should use the `primary`. The central hypothesis is the following: `The WebUI performance of the primary is acceptable to users independent of their location.` Firstly, we need to try and validate this hypothesis before proceeding. I will open [a UX research request](https://about.gitlab.com/handbook/engineering/ux/ux-research/#how-to-request-research) and ask for help so we can test this hypothesis with users of Geo. I'd also love to know if and how users use the read-only web UIs at all. If it turns out that users are happy/find it acceptable to use the `primary` web UI, or if they prefer this solution over the current state, we can direct all regular users to the primary URL e.g. `https://gitlab.example.com` and use the `secondary` UI only for admin tasks/DR. Following this, we should investigate how we can still leverage the `secondaries` to improve the performance of the `primary` . Maybe performance improves if we serve static assets from the closest `secondary`? Maybe we can proxy read-only requests as well? This is the inverse of some of the POCs so far. The user experience for the `primary` web UI would still be something to improve. Also, this does not mean we won't attempt to create a true `active-active` Geo setup later. However, this effort would be hidden from Geo users and would not likely result in any further configuration changes - it would be a true backend improvement that may impact performance and potentially DR capabilities. ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> 1. Users need no concept of Geo/primary/secondary 1. Users' web experience is simplified 1. Users' git experience is simplified (no more configuration changes) 1. Users' git experience is always the fastest, if latency-based or geoproximity-based routing is configured 1. Sysadmins don't need to help users understand Geo anymore 1. We save potentially a lot of development effort for better things ### What is the type of buyer? <!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> * Premium * Ultimate ### Links / references