Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
6e11ac78e9
commit
9dadb12cf2
|
|
@ -642,7 +642,7 @@ lib/gitlab/checks/** @proglottis @toon @zj-gitlab
|
|||
/doc/user/admin_area/credentials_inventory.md @eread
|
||||
/doc/user/admin_area/custom_project_templates.md @eread
|
||||
/doc/user/admin_area/diff_limits.md @aqualls
|
||||
/doc/user/admin_area/geo_nodes.md @axil
|
||||
/doc/user/admin_area/geo_sites.md @axil
|
||||
/doc/user/admin_area/labels.md @msedlakjakubowski
|
||||
/doc/user/admin_area/license_file.md @sselhorn
|
||||
/doc/user/admin_area/license.md @sselhorn
|
||||
|
|
|
|||
|
|
@ -2,4 +2,3 @@
|
|||
Gitlab/DelegatePredicateMethods:
|
||||
Exclude:
|
||||
- app/models/clusters/cluster.rb
|
||||
- ee/app/models/concerns/ee/ci/metadatable.rb
|
||||
|
|
|
|||
|
|
@ -329,7 +329,7 @@ export default {
|
|||
</div>
|
||||
|
||||
<p class="gl-mt-n5 gl-text-gray-500">
|
||||
{{ s__('ForkProject|Want to house several dependent projects under the same namespace?') }}
|
||||
{{ s__('ForkProject|Want to organize several dependent projects under the same namespace?') }}
|
||||
<gl-link :href="newGroupPath" target="_blank">
|
||||
{{ s__('ForkProject|Create a group') }}
|
||||
</gl-link>
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ const PANELS = [
|
|||
selector: '#blank-project-pane',
|
||||
title: s__('ProjectsNew|Create blank project'),
|
||||
description: s__(
|
||||
'ProjectsNew|Create a blank project to house your files, plan your work, and collaborate on code, among other things.',
|
||||
'ProjectsNew|Create a blank project to store your files, plan your work, and collaborate on code, among other things.',
|
||||
),
|
||||
illustration: blankProjectIllustration,
|
||||
},
|
||||
|
|
|
|||
|
|
@ -92,7 +92,7 @@ export default {
|
|||
>
|
||||
<template #default="{ dismiss }">
|
||||
<aside
|
||||
class="gl-fixed gl-bottom-0 gl-right-0 gl-z-index-200 gl-p-5"
|
||||
class="gl-fixed gl-bottom-0 gl-right-0 gl-z-index-9999 gl-p-5"
|
||||
:aria-label="$options.i18n.survey"
|
||||
>
|
||||
<transition name="survey-slide-up">
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@
|
|||
- if current_user.can_create_group?
|
||||
.form-text.text-muted
|
||||
- link_start_group_path = '<a href="%{path}">' % { path: new_group_path }
|
||||
- project_tip = s_('ProjectsNew|Want to house several dependent projects under the same namespace? %{link_start}Create a group.%{link_end}') % { link_start: link_start_group_path, link_end: '</a>' }
|
||||
- project_tip = s_('ProjectsNew|Want to organize several dependent projects under the same namespace? %{link_start}Create a group.%{link_end}') % { link_start: link_start_group_path, link_end: '</a>' }
|
||||
= project_tip.html_safe
|
||||
= render Pajamas::AlertComponent.new(alert_options: { class: "gl-mb-4 gl-display-none js-user-readme-repo" },
|
||||
dismissible: false,
|
||||
|
|
|
|||
|
|
@ -183,7 +183,7 @@ This machine's Geo node name matches a database record ... no
|
|||
```
|
||||
|
||||
Learn more about recommended site names in the description of the Name field in
|
||||
[Geo Admin Area Common Settings](../../../user/admin_area/geo_nodes.md#common-settings).
|
||||
[Geo Admin Area Common Settings](../../../user/admin_area/geo_sites.md#common-settings).
|
||||
|
||||
### Message: `WARNING: oldest xmin is far in the past` and `pg_wal` size growing
|
||||
|
||||
|
|
|
|||
|
|
@ -287,6 +287,9 @@ can supply the ID by either:
|
|||
- Dynamically adding the `data-merge-request-id` value during the build of the app.
|
||||
- Supplying it manually through the visual review form in the app.
|
||||
|
||||
If the ID is missing from the `script`, the visual review tool prompts you to enter the
|
||||
merge request ID before you can provide feedback.
|
||||
|
||||
### Authentication for Visual Reviews
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/42750#note_317271120) in GitLab 12.10.
|
||||
|
|
|
|||
|
|
@ -6,8 +6,11 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
# Multiple Databases
|
||||
|
||||
To scale GitLab, the we are
|
||||
[decomposing the GitLab application database into multiple databases](https://gitlab.com/groups/gitlab-org/-/epics/6168).
|
||||
To allow GitLab to scale further we
|
||||
[decomposed the GitLab application database into multiple
|
||||
databases](https://gitlab.com/groups/gitlab-org/-/epics/6168). The two databases
|
||||
are `main` and `ci`. GitLab supports being run with either one database or two databases.
|
||||
On GitLab.com we are using two separate databases.
|
||||
|
||||
## GitLab Schema
|
||||
|
||||
|
|
@ -40,7 +43,7 @@ The `gitlab_schema` primary purpose is to introduce a barrier between different
|
|||
|
||||
This is used as a primary source of classification for:
|
||||
|
||||
- [Discovering cross-joins across tables from different schemas](#removing-joins-between-ci_-and-non-ci_-tables)
|
||||
- [Discovering cross-joins across tables from different schemas](#removing-joins-between-ci-and-non-ci-tables)
|
||||
- [Discovering cross-database transactions across tables from different schemas](#removing-cross-database-transactions)
|
||||
|
||||
### The special purpose of `gitlab_shared`
|
||||
|
|
@ -72,10 +75,6 @@ Read [Migrations for Multiple Databases](migrations_for_multiple_databases.md).
|
|||
|
||||
## CI/CD Database
|
||||
|
||||
> Support for configuring the GitLab Rails application to use a distinct
|
||||
database for CI/CD tables was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/64289)
|
||||
in GitLab 14.1. This feature is still under development, and is not ready for production use.
|
||||
|
||||
### Configure single database
|
||||
|
||||
By default, GDK is configured to run with multiple databases.
|
||||
|
|
@ -107,32 +106,14 @@ NOTE: The `validate_cross_joins!` method in `spec/support/database/prevent_cross
|
|||
the corresponding documentation URL used in `spec/support/database/prevent_cross_joins.rb`.
|
||||
-->
|
||||
|
||||
### Removing joins between `ci_*` and non `ci_*` tables
|
||||
### Removing joins between `ci` and non `ci` tables
|
||||
|
||||
Queries that join across databases raise an error. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68620)
|
||||
in GitLab 14.3, for new queries only. Pre-existing queries do not raise an error.
|
||||
|
||||
We are planning on moving all the `ci_*` tables to a separate database, so
|
||||
referencing `ci_*` tables with other tables will not be possible. This means,
|
||||
that using any kind of `JOIN` in SQL queries will not work. We have identified
|
||||
already many such examples that need to be fixed in
|
||||
<https://gitlab.com/groups/gitlab-org/-/epics/6289> .
|
||||
|
||||
#### Path to removing cross-database joins
|
||||
|
||||
The following steps are the process to remove cross-database joins between
|
||||
`ci_*` and non `ci_*` tables:
|
||||
|
||||
1. **{check-circle}** Add all failing specs to the [`cross-join-allowlist.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/support/database/cross-join-allowlist.yml)
|
||||
file.
|
||||
1. **{check-circle}** Find the code that caused the spec failure and wrap the isolated code
|
||||
in [`allow_cross_joins_across_databases`](#allowlist-for-existing-cross-joins).
|
||||
Link to a new issue assigned to the correct team to remove the specs from the
|
||||
`cross-join-allowlist.yml` file.
|
||||
1. **{dotted-circle}** Remove the `cross-join-allowlist.yml` file and stop allowing
|
||||
whole test files.
|
||||
1. **{dotted-circle}** Fix the problem and remove the `allow_cross_joins_across_databases` call.
|
||||
1. **{dotted-circle}** Fix all the cross-joins and remove the `allow_cross_joins_across_databases` method.
|
||||
Because GitLab can be run with multiple separate databases, referencing `ci`
|
||||
tables with non `ci` tables in a single query is not possible. Therefore,
|
||||
using any kind of `JOIN` in SQL queries will not work.
|
||||
|
||||
#### Suggestions for removing cross-database joins
|
||||
|
||||
|
|
@ -416,13 +397,10 @@ query or look at other patterns described above for removing cross-joins.
|
|||
|
||||
#### How to validate you have correctly removed a cross-join
|
||||
|
||||
Using RSpec tests, you can validate all SQL queries within a code block to
|
||||
ensure that none of them are joining across the two databases. This is a useful
|
||||
tool to confirm you have correctly fixed an existing cross-join.
|
||||
|
||||
At some point in the future we will have fixed all cross-joins and this tool
|
||||
will run by default in all tests. For now, the tool needs to be explicitly enabled
|
||||
for your test.
|
||||
RSpec is configured to automatically validate all SQL queries do not join
|
||||
across databases. If this validation is disabled in
|
||||
`spec/support/database/cross-join-allowlist.yml` then you can still validate an
|
||||
isolated code block using `with_cross_joins_prevented`.
|
||||
|
||||
You can use this method like so:
|
||||
|
||||
|
|
@ -553,12 +531,11 @@ The `MyAsyncConsistencyJob` would also attempt to update the timestamp if they d
|
|||
|
||||
At this point, we don't have the tooling (we might not even need it) to ensure similar consistency
|
||||
characteristics as we had with one database. If you think that the code you're working on requires
|
||||
these properties, then you can disable the cross-database modification check by wrapping to
|
||||
offending database queries with a block and create a follow-up issue mentioning the sharding group
|
||||
(`gitlab-org/sharding-group`).
|
||||
these properties, then you can disable the cross-database modification check in your tests by wrapping the
|
||||
offending test code with a block and create a follow-up issue.
|
||||
|
||||
```ruby
|
||||
Gitlab::Database.allow_cross_joins_across_databases(url: 'gitlab issue URL') do
|
||||
allow_cross_database_modification_within_transaction(url: 'gitlab issue URL') do
|
||||
ApplicationRecord.transaction do
|
||||
ci_build.update!(updated_at: Time.current) # UPDATE on CI DB
|
||||
ci_build.project.update!(updated_at: Time.current) # UPDATE on Main DB
|
||||
|
|
@ -567,7 +544,7 @@ end
|
|||
```
|
||||
|
||||
Don't hesitate to reach out to the
|
||||
[sharding group](https://about.gitlab.com/handbook/engineering/development/enablement/sharding/)
|
||||
[pods group](https://about.gitlab.com/handbook/engineering/development/enablement/data_stores/pods/)
|
||||
for advice.
|
||||
|
||||
##### Avoid `dependent: :nullify` and `dependent: :destroy` across databases
|
||||
|
|
|
|||
|
|
@ -97,7 +97,7 @@ projects that need updating. Those projects can be:
|
|||
timestamp that is more recent than the `last_repository_successful_sync_at`
|
||||
timestamp in the `Geo::ProjectRegistry` model.
|
||||
- Manual: The administrator can manually flag a repository to resync in the
|
||||
[Geo Admin Area](../user/admin_area/geo_nodes.md).
|
||||
[Geo Admin Area](../user/admin_area/geo_sites.md).
|
||||
|
||||
When we fail to fetch a repository on the secondary `RETRIES_BEFORE_REDOWNLOAD`
|
||||
times, Geo does a so-called _re-download_. It will do a clean clone
|
||||
|
|
@ -437,7 +437,7 @@ basically hashes all Git refs together and stores that hash in the
|
|||
The **secondary** site does the same to calculate the hash of its
|
||||
clone, and compares the hash with the value the **primary** site
|
||||
calculated. If there is a mismatch, Geo will mark this as a mismatch
|
||||
and the administrator can see this in the [Geo Admin Area](../user/admin_area/geo_nodes.md).
|
||||
and the administrator can see this in the [Geo Admin Area](../user/admin_area/geo_sites.md).
|
||||
|
||||
## Glossary
|
||||
|
||||
|
|
|
|||
|
|
@ -83,6 +83,8 @@ The following are important notes about 2FA:
|
|||
1. Uncheck the **Allow subgroups to set up their own two-factor authentication rule** field.
|
||||
|
||||
This action causes all subgroups with 2FA requirements to stop requiring that from their members.
|
||||
- Access tokens are not required to provide a second factor for authentication because they are API-based.
|
||||
Tokens generated before 2FA is enforced remain valid.
|
||||
|
||||
## Disable 2FA
|
||||
|
||||
|
|
|
|||
|
|
@ -1,117 +1,11 @@
|
|||
---
|
||||
stage: Systems
|
||||
group: Geo
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
|
||||
redirect_to: 'geo_sites.md'
|
||||
remove_date: '2022-10-05'
|
||||
---
|
||||
|
||||
# Geo sites Admin Area **(PREMIUM SELF)**
|
||||
This document was moved to [another location](geo_sites.md).
|
||||
|
||||
You can configure various settings for GitLab Geo sites. For more information, see
|
||||
[Geo documentation](../../administration/geo/index.md).
|
||||
|
||||
On either the primary or secondary site:
|
||||
|
||||
1. On the top bar, select **Menu > Admin**.
|
||||
1. On the left sidebar, select **Geo > Sites**.
|
||||
|
||||
## Common settings
|
||||
|
||||
All Geo sites have the following settings:
|
||||
|
||||
| Setting | Description |
|
||||
| --------| ----------- |
|
||||
| Primary | This marks a Geo site as **primary** site. There can be only one **primary** site. |
|
||||
| Name | The unique identifier for the Geo site. It's highly recommended to use a physical location as a name. Good examples are "London Office" or "us-east-1". Avoid words like "primary", "secondary", "Geo", or "DR". This makes the failover process easier because the physical location does not change, but the Geo site role can. All nodes in a single Geo site use the same site name. Nodes use the `gitlab_rails['geo_node_name']` setting in `/etc/gitlab/gitlab.rb` to lookup their Geo site record in the PostgreSQL database. If `gitlab_rails['geo_node_name']` is not set, the node's `external_url` with trailing slash is used as fallback. The value of `Name` is case-sensitive, and most characters are allowed. |
|
||||
| URL | The instance's user-facing URL. |
|
||||
|
||||
The site you're currently browsing is indicated with a blue `Current` label, and
|
||||
the **primary** node is listed first as `Primary site`.
|
||||
|
||||
## Secondary site settings
|
||||
|
||||
**Secondary** sites have a number of additional settings available:
|
||||
|
||||
| Setting | Description |
|
||||
|---------------------------|-------------|
|
||||
| Selective synchronization | Enable Geo [selective sync](../../administration/geo/replication/configuration.md#selective-synchronization) for this **secondary** site. |
|
||||
| Repository sync capacity | Number of concurrent requests this **secondary** site makes to the **primary** site when backfilling repositories. |
|
||||
| File sync capacity | Number of concurrent requests this **secondary** site makes to the **primary** site when backfilling files. |
|
||||
|
||||
## Geo backfill
|
||||
|
||||
**Secondary** sites are notified of changes to repositories and files by the **primary** site,
|
||||
and always attempt to synchronize those changes as quickly as possible.
|
||||
|
||||
Backfill is the act of populating the **secondary** site with repositories and files that
|
||||
existed *before* the **secondary** site was added to the database. Because there may be
|
||||
extremely large numbers of repositories and files, it's not feasible to attempt to
|
||||
download them all at once; so, GitLab places an upper limit on the concurrency of
|
||||
these operations.
|
||||
|
||||
How long the backfill takes is dependent on the maximum concurrency, but higher
|
||||
values place more strain on the **primary** site. The limits are configurable.
|
||||
If your **primary** site has lots of surplus capacity,
|
||||
you can increase the values to complete backfill in a shorter time. If it's
|
||||
under heavy load and backfill reduces its availability for normal requests,
|
||||
you can decrease them.
|
||||
|
||||
## Set up the internal URLs
|
||||
|
||||
> Setting up internal URLs in secondary sites was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/77179) in GitLab 14.7.
|
||||
|
||||
You can set up a different URL for synchronization between the primary and secondary site.
|
||||
|
||||
The **primary** site's Internal URL is used by **secondary** sites to contact it
|
||||
(to sync repositories, for example). The name Internal URL distinguishes it from
|
||||
[External URL](https://docs.gitlab.com/omnibus/settings/configuration.html#configuring-the-external-url-for-gitlab),
|
||||
which is used by users. Internal URL does not need to be a private address.
|
||||
|
||||
When [Geo secondary proxying](../../administration/geo/secondary_proxy/index.md) is enabled,
|
||||
the primary uses the secondary's internal URL to contact it directly.
|
||||
|
||||
The internal URL defaults to external URL. To change it:
|
||||
|
||||
1. On the top bar, select **Menu > Admin**.
|
||||
1. On the left sidebar, select **Geo > Nodes**.
|
||||
1. Select **Edit** on the site you want to customize.
|
||||
1. Edit the internal URL.
|
||||
1. Select **Save changes**.
|
||||
|
||||
When enabled, the Admin Area for Geo shows replication details for each site directly
|
||||
from the primary site's UI, and through the Geo secondary proxy, if enabled.
|
||||
|
||||
WARNING:
|
||||
We recommend using an HTTPS connection while configuring the Geo sites. To avoid
|
||||
breaking communication between **primary** and **secondary** sites when using
|
||||
HTTPS, customize your Internal URL to point to a load balancer with TLS
|
||||
terminated at the load balancer.
|
||||
|
||||
WARNING:
|
||||
Starting with GitLab 13.3 and [until 13.11](https://gitlab.com/gitlab-org/gitlab/-/issues/325522),
|
||||
if you use an internal URL that is not accessible to the users, the
|
||||
OAuth authorization flow does not work properly, because users are redirected
|
||||
to the internal URL instead of the external one.
|
||||
|
||||
## Multiple secondary sites behind a load balancer
|
||||
|
||||
**Secondary** sites can use identical external URLs if
|
||||
a unique `name` is set for each Geo site. The `gitlab.rb` setting
|
||||
`gitlab_rails['geo_node_name']` must:
|
||||
|
||||
- Be set for each GitLab instance that runs `puma`, `sidekiq`, or `geo_logcursor`.
|
||||
- Match a Geo site name.
|
||||
|
||||
The load balancer must use sticky sessions to avoid authentication
|
||||
failures and cross-site request errors.
|
||||
|
||||
<!-- ## Troubleshooting
|
||||
|
||||
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
|
||||
one might have when setting this up, or when something is changed, or on upgrading, it's
|
||||
important to describe those, too. Think of things that may go wrong and include them here.
|
||||
This is important to minimize requests for support, and to avoid doc comments with
|
||||
questions that you know someone might ask.
|
||||
|
||||
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
|
||||
If you have none to add when creating a doc, leave this section in place
|
||||
but commented out to help encourage others to add to it in the future. -->
|
||||
<!-- This redirect file can be deleted after <2022-10-05>. -->
|
||||
<!-- Redirects that point to other docs in the same project expire in three months. -->
|
||||
<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
|
||||
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
|
||||
|
|
|
|||
|
|
@ -0,0 +1,117 @@
|
|||
---
|
||||
stage: Systems
|
||||
group: Geo
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
|
||||
---
|
||||
|
||||
# Geo sites Admin Area **(PREMIUM SELF)**
|
||||
|
||||
You can configure various settings for GitLab Geo sites. For more information, see
|
||||
[Geo documentation](../../administration/geo/index.md).
|
||||
|
||||
On either the primary or secondary site:
|
||||
|
||||
1. On the top bar, select **Menu > Admin**.
|
||||
1. On the left sidebar, select **Geo > Sites**.
|
||||
|
||||
## Common settings
|
||||
|
||||
All Geo sites have the following settings:
|
||||
|
||||
| Setting | Description |
|
||||
| --------| ----------- |
|
||||
| Primary | This marks a Geo site as **primary** site. There can be only one **primary** site. |
|
||||
| Name | The unique identifier for the Geo site. It's highly recommended to use a physical location as a name. Good examples are "London Office" or "us-east-1". Avoid words like "primary", "secondary", "Geo", or "DR". This makes the failover process easier because the physical location does not change, but the Geo site role can. All nodes in a single Geo site use the same site name. Nodes use the `gitlab_rails['geo_node_name']` setting in `/etc/gitlab/gitlab.rb` to lookup their Geo site record in the PostgreSQL database. If `gitlab_rails['geo_node_name']` is not set, the node's `external_url` with trailing slash is used as fallback. The value of `Name` is case-sensitive, and most characters are allowed. |
|
||||
| URL | The instance's user-facing URL. |
|
||||
|
||||
The site you're currently browsing is indicated with a blue `Current` label, and
|
||||
the **primary** node is listed first as `Primary site`.
|
||||
|
||||
## Secondary site settings
|
||||
|
||||
**Secondary** sites have a number of additional settings available:
|
||||
|
||||
| Setting | Description |
|
||||
|---------------------------|-------------|
|
||||
| Selective synchronization | Enable Geo [selective sync](../../administration/geo/replication/configuration.md#selective-synchronization) for this **secondary** site. |
|
||||
| Repository sync capacity | Number of concurrent requests this **secondary** site makes to the **primary** site when backfilling repositories. |
|
||||
| File sync capacity | Number of concurrent requests this **secondary** site makes to the **primary** site when backfilling files. |
|
||||
|
||||
## Geo backfill
|
||||
|
||||
**Secondary** sites are notified of changes to repositories and files by the **primary** site,
|
||||
and always attempt to synchronize those changes as quickly as possible.
|
||||
|
||||
Backfill is the act of populating the **secondary** site with repositories and files that
|
||||
existed *before* the **secondary** site was added to the database. Because there may be
|
||||
extremely large numbers of repositories and files, it's not feasible to attempt to
|
||||
download them all at once; so, GitLab places an upper limit on the concurrency of
|
||||
these operations.
|
||||
|
||||
How long the backfill takes is dependent on the maximum concurrency, but higher
|
||||
values place more strain on the **primary** site. The limits are configurable.
|
||||
If your **primary** site has lots of surplus capacity,
|
||||
you can increase the values to complete backfill in a shorter time. If it's
|
||||
under heavy load and backfill reduces its availability for normal requests,
|
||||
you can decrease them.
|
||||
|
||||
## Set up the internal URLs
|
||||
|
||||
> Setting up internal URLs in secondary sites was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/77179) in GitLab 14.7.
|
||||
|
||||
You can set up a different URL for synchronization between the primary and secondary site.
|
||||
|
||||
The **primary** site's Internal URL is used by **secondary** sites to contact it
|
||||
(to sync repositories, for example). The name Internal URL distinguishes it from
|
||||
[External URL](https://docs.gitlab.com/omnibus/settings/configuration.html#configuring-the-external-url-for-gitlab),
|
||||
which is used by users. Internal URL does not need to be a private address.
|
||||
|
||||
When [Geo secondary proxying](../../administration/geo/secondary_proxy/index.md) is enabled,
|
||||
the primary uses the secondary's internal URL to contact it directly.
|
||||
|
||||
The internal URL defaults to external URL. To change it:
|
||||
|
||||
1. On the top bar, select **Menu > Admin**.
|
||||
1. On the left sidebar, select **Geo > Sites**.
|
||||
1. Select **Edit** on the site you want to customize.
|
||||
1. Edit the internal URL.
|
||||
1. Select **Save changes**.
|
||||
|
||||
When enabled, the Admin Area for Geo shows replication details for each site directly
|
||||
from the primary site's UI, and through the Geo secondary proxy, if enabled.
|
||||
|
||||
WARNING:
|
||||
We recommend using an HTTPS connection while configuring the Geo sites. To avoid
|
||||
breaking communication between **primary** and **secondary** sites when using
|
||||
HTTPS, customize your Internal URL to point to a load balancer with TLS
|
||||
terminated at the load balancer.
|
||||
|
||||
WARNING:
|
||||
Starting with GitLab 13.3 and [until 13.11](https://gitlab.com/gitlab-org/gitlab/-/issues/325522),
|
||||
if you use an internal URL that is not accessible to the users, the
|
||||
OAuth authorization flow does not work properly, because users are redirected
|
||||
to the internal URL instead of the external one.
|
||||
|
||||
## Multiple secondary sites behind a load balancer
|
||||
|
||||
**Secondary** sites can use identical external URLs if
|
||||
a unique `name` is set for each Geo site. The `gitlab.rb` setting
|
||||
`gitlab_rails['geo_node_name']` must:
|
||||
|
||||
- Be set for each GitLab instance that runs `puma`, `sidekiq`, or `geo_logcursor`.
|
||||
- Match a Geo site name.
|
||||
|
||||
The load balancer must use sticky sessions to avoid authentication
|
||||
failures and cross-site request errors.
|
||||
|
||||
<!-- ## Troubleshooting
|
||||
|
||||
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
|
||||
one might have when setting this up, or when something is changed, or on upgrading, it's
|
||||
important to describe those, too. Think of things that may go wrong and include them here.
|
||||
This is important to minimize requests for support, and to avoid doc comments with
|
||||
questions that you know someone might ask.
|
||||
|
||||
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
|
||||
If you have none to add when creating a doc, leave this section in place
|
||||
but commented out to help encourage others to add to it in the future. -->
|
||||
|
|
@ -33,7 +33,7 @@ The Admin Area is made up of the following sections:
|
|||
| **{license}** License | Add, display, and remove [licenses](license.md). |
|
||||
| **{cloud-gear}** Kubernetes | Create and manage instance-level [Kubernetes clusters](../instance/clusters/index.md). |
|
||||
| **{push-rules}** Push rules | Configure pre-defined Git [push rules](../project/repository/push_rules.md) for projects. Also, configure [merge requests approvers rules](merge_requests_approvals.md). |
|
||||
| **{location-dot}** Geo | Configure and maintain [Geo nodes](geo_nodes.md). |
|
||||
| **{location-dot}** Geo | Configure and maintain [Geo sites](geo_sites.md). |
|
||||
| **{key}** Deploy keys | Create instance-wide [SSH deploy keys](../project/deploy_keys/index.md). |
|
||||
| **{lock}** Credentials | View [credentials](credentials_inventory.md) that can be used to access your instance. |
|
||||
| **{template}** Integrations | Manage [instance-level default settings](settings/project_integration_management.md) for a project integration. |
|
||||
|
|
|
|||
|
|
@ -59,11 +59,12 @@ To enable 2FA with a one-time password:
|
|||
1. Select **Enable Two-factor Authentication**.
|
||||
1. **On your device (usually your phone):**
|
||||
1. Install a compatible application. For example:
|
||||
- [Aegis](https://getaegis.app/)
|
||||
- [Raivo OTP](https://apps.apple.com/us/app/raivo-otp/id1459042137#platform=iphone)
|
||||
- [Authy](https://authy.com/)
|
||||
- [Duo Mobile](https://duo.com/product/multi-factor-authentication-mfa/duo-mobile-app)
|
||||
- [LastPass Authenticator](https://lastpass.com/auth/)
|
||||
- [Authenticator](https://mattrubin.me/authenticator/)
|
||||
- [andOTP](https://github.com/andOTP/andOTP)
|
||||
- [Google Authenticator](https://support.google.com/accounts/answer/1066447?hl=en)
|
||||
- [Microsoft Authenticator](https://www.microsoft.com/en-us/security/mobile-authenticator-app)
|
||||
- [SailOTP](https://openrepos.net/content/seiichiro0185/sailotp)
|
||||
|
|
|
|||
|
|
@ -16569,7 +16569,7 @@ msgstr ""
|
|||
msgid "ForkProject|Visibility level"
|
||||
msgstr ""
|
||||
|
||||
msgid "ForkProject|Want to house several dependent projects under the same namespace?"
|
||||
msgid "ForkProject|Want to organize several dependent projects under the same namespace?"
|
||||
msgstr ""
|
||||
|
||||
msgid "ForkSuggestion|Cancel"
|
||||
|
|
@ -19218,9 +19218,6 @@ msgstr ""
|
|||
msgid "Hour (UTC)"
|
||||
msgstr ""
|
||||
|
||||
msgid "House your files, plan your work, collaborate on code, and more."
|
||||
msgstr ""
|
||||
|
||||
msgid "Housekeeping"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -30785,7 +30782,7 @@ msgstr ""
|
|||
msgid "ProjectsNew|Create"
|
||||
msgstr ""
|
||||
|
||||
msgid "ProjectsNew|Create a blank project to house your files, plan your work, and collaborate on code, among other things."
|
||||
msgid "ProjectsNew|Create a blank project to store your files, plan your work, and collaborate on code, among other things."
|
||||
msgstr ""
|
||||
|
||||
msgid "ProjectsNew|Create a project pre-populated with the necessary files to get you started quickly."
|
||||
|
|
@ -30845,7 +30842,7 @@ msgstr ""
|
|||
msgid "ProjectsNew|Visibility Level"
|
||||
msgstr ""
|
||||
|
||||
msgid "ProjectsNew|Want to house several dependent projects under the same namespace? %{link_start}Create a group.%{link_end}"
|
||||
msgid "ProjectsNew|Want to organize several dependent projects under the same namespace? %{link_start}Create a group.%{link_end}"
|
||||
msgstr ""
|
||||
|
||||
msgid "PrometheusAlerts|exceeded"
|
||||
|
|
@ -37081,6 +37078,9 @@ msgstr ""
|
|||
msgid "StorageSize|Unknown"
|
||||
msgstr ""
|
||||
|
||||
msgid "Store your files, plan your work, collaborate on code, and more."
|
||||
msgstr ""
|
||||
|
||||
msgid "Strikethrough"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -39801,7 +39801,7 @@ msgstr ""
|
|||
msgid "This project will be deleted on %{date} since its parent group '%{parent_group_name}' has been scheduled for deletion."
|
||||
msgstr ""
|
||||
|
||||
msgid "This project will live in your group %{strong_open}%{namespace}%{strong_close}. A project is where you house your files (repository), plan your work (issues), publish your documentation (wiki), and so much more."
|
||||
msgid "This project will live in your group %{strong_open}%{namespace}%{strong_close}. A project is where you store your files (repository), plan your work (issues), publish your documentation (wiki), and so much more."
|
||||
msgstr ""
|
||||
|
||||
msgid "This repository"
|
||||
|
|
|
|||
Loading…
Reference in New Issue