Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
parent
f9ddf689da
commit
3f5cfe826b
|
@ -56,6 +56,7 @@ export default {
|
|||
<div class="pipeline-tags" data-testid="pipeline-url-table-cell">
|
||||
<gl-link
|
||||
:href="pipeline.path"
|
||||
class="gl-text-decoration-underline"
|
||||
data-testid="pipeline-url-link"
|
||||
data-qa-selector="pipeline_url_link"
|
||||
>
|
||||
|
|
|
@ -35,7 +35,7 @@ required scheduled maintenance period significantly.
|
|||
A common strategy for keeping this period as short as possible for data stored
|
||||
in files is to use `rsync` to transfer the data. An initial `rsync` can be
|
||||
performed ahead of the maintenance window; subsequent `rsync`s (including a
|
||||
final transfer inside the maintenance window) will then transfer only the
|
||||
final transfer inside the maintenance window) then transfers only the
|
||||
*changes* between the **primary** node and the **secondary** nodes.
|
||||
|
||||
Repository-centric strategies for using `rsync` effectively can be found in the
|
||||
|
@ -50,7 +50,7 @@ this command reports `ERROR - Replication is not up-to-date` even if
|
|||
replication is actually up-to-date. This bug was fixed in GitLab 13.8 and
|
||||
later.
|
||||
|
||||
Run this command to list out all preflight checks and automatically check if replication and verification are complete before scheduling a planned failover to ensure the process will go smoothly:
|
||||
Run this command to list out all preflight checks and automatically check if replication and verification are complete before scheduling a planned failover to ensure the process goes smoothly:
|
||||
|
||||
```shell
|
||||
gitlab-ctl promotion-preflight-checks
|
||||
|
@ -73,7 +73,7 @@ In GitLab 12.4, you can optionally allow GitLab to manage replication of Object
|
|||
Database settings are automatically replicated to the **secondary** node, but the
|
||||
`/etc/gitlab/gitlab.rb` file must be set up manually, and differs between
|
||||
nodes. If features such as Mattermost, OAuth or LDAP integration are enabled
|
||||
on the **primary** node but not the **secondary** node, they will be lost during failover.
|
||||
on the **primary** node but not the **secondary** node, they are lost during failover.
|
||||
|
||||
Review the `/etc/gitlab/gitlab.rb` file for both nodes and ensure the **secondary** node
|
||||
supports everything the **primary** node does **before** scheduling a planned failover.
|
||||
|
@ -119,7 +119,7 @@ time to complete
|
|||
|
||||
If any objects are failing to replicate, this should be investigated before
|
||||
scheduling the maintenance window. Following a planned failover, anything that
|
||||
failed to replicate will be **lost**.
|
||||
failed to replicate is **lost**.
|
||||
|
||||
You can use the [Geo status API](../../../api/geo_nodes.md#retrieve-project-sync-or-verification-failures-that-occurred-on-the-current-node) to review failed objects and
|
||||
the reasons for failure.
|
||||
|
@ -136,9 +136,9 @@ This [content was moved to another location](background_verification.md).
|
|||
|
||||
On the **primary** node, navigate to **Admin Area > Messages**, add a broadcast
|
||||
message. You can check under **Admin Area > Geo** to estimate how long it
|
||||
will take to finish syncing. An example message would be:
|
||||
takes to finish syncing. An example message would be:
|
||||
|
||||
> A scheduled maintenance will take place at XX:XX UTC. We expect it to take
|
||||
> A scheduled maintenance takes place at XX:XX UTC. We expect it to take
|
||||
> less than 1 hour.
|
||||
|
||||
## Prevent updates to the **primary** node
|
||||
|
@ -151,7 +151,7 @@ be disabled on the primary site:
|
|||
1. Disable non-Geo periodic background jobs on the **primary** node by navigating
|
||||
to **Admin Area > Monitoring > Background Jobs > Cron**, pressing `Disable All`,
|
||||
and then pressing `Enable` for the `geo_sidekiq_cron_config_worker` cron job.
|
||||
This job will re-enable several other cron jobs that are essential for planned
|
||||
This job re-enables several other cron jobs that are essential for planned
|
||||
failover to complete successfully.
|
||||
|
||||
## Finish replicating and verifying all data
|
||||
|
@ -161,7 +161,7 @@ be disabled on the primary site:
|
|||
1. On the **primary** node, navigate to **Admin Area > Monitoring > Background Jobs > Queues**
|
||||
and wait for all queues except those with `geo` in the name to drop to 0.
|
||||
These queues contain work that has been submitted by your users; failing over
|
||||
before it is completed will cause the work to be lost.
|
||||
before it is completed, causes the work to be lost.
|
||||
1. On the **primary** node, navigate to **Admin Area > Geo** and wait for the
|
||||
following conditions to be true of the **secondary** node you are failing over to:
|
||||
|
||||
|
@ -176,15 +176,15 @@ be disabled on the primary site:
|
|||
to verify the integrity of CI artifacts, LFS objects, and uploads in file
|
||||
storage.
|
||||
|
||||
At this point, your **secondary** node will contain an up-to-date copy of everything the
|
||||
**primary** node has, meaning nothing will be lost when you fail over.
|
||||
At this point, your **secondary** node contains an up-to-date copy of everything the
|
||||
**primary** node has, meaning nothing was lost when you fail over.
|
||||
|
||||
## Promote the **secondary** node
|
||||
|
||||
Finally, follow the [Disaster Recovery docs](index.md) to promote the
|
||||
**secondary** node to a **primary** node. This process will cause a brief outage on the **secondary** node, and users may need to log in again.
|
||||
**secondary** node to a **primary** node. This process causes a brief outage on the **secondary** node, and users may need to log in again.
|
||||
|
||||
Once it is completed, the maintenance window is over! Your new **primary** node will now
|
||||
Once it is completed, the maintenance window is over! Your new **primary** node, now
|
||||
begin to diverge from the old one. If problems do arise at this point, failing
|
||||
back to the old **primary** node [is possible](bring_primary_back.md), but likely to result
|
||||
in the loss of any data uploaded to the new **primary** in the meantime.
|
||||
|
|
|
@ -169,8 +169,8 @@ Read more about [Gitaly concurrency limits](gitaly/configure_gitaly.md#limit-rpc
|
|||
|
||||
There's a limit to the number of comments that can be submitted on an issue,
|
||||
merge request, or commit. When the limit is reached, system notes can still be
|
||||
added so that the history of events is not lost, but user-submitted comments
|
||||
will fail.
|
||||
added so that the history of events is not lost, but the user-submitted
|
||||
comment fails.
|
||||
|
||||
- **Max limit**: 5,000 comments.
|
||||
|
||||
|
@ -179,10 +179,10 @@ will fail.
|
|||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/61974) in GitLab 12.2.
|
||||
|
||||
There is a limit to the size of comments and descriptions of issues, merge requests, and epics.
|
||||
Attempting to add a body of text larger than the limit will result in an error, and the
|
||||
item will not be created.
|
||||
Attempting to add a body of text larger than the limit, results in an error, and the
|
||||
item is also not created.
|
||||
|
||||
It's possible that this limit will be changed to a lower number in the future.
|
||||
It's possible that this limit changes to a lower number in the future.
|
||||
|
||||
- **Max size**: ~1 million characters / ~1 MB.
|
||||
|
||||
|
@ -191,8 +191,8 @@ It's possible that this limit will be changed to a lower number in the future.
|
|||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/292039) in GitLab 13.9
|
||||
|
||||
Commits with arbitrarily large messages may be pushed to GitLab, but when
|
||||
displaying commits, titles (the first line of the commit message) will be
|
||||
limited to 1KiB, and descriptions (the rest of the message) will be limited to
|
||||
displaying commits, titles (the first line of the commit message)
|
||||
limits to 1KiB, and descriptions (the rest of the message) limits to
|
||||
1MiB.
|
||||
|
||||
## Number of issues in the milestone overview
|
||||
|
@ -316,7 +316,7 @@ each time a new pipeline is created. An active pipeline is any pipeline in one o
|
|||
- `running`
|
||||
|
||||
If a new pipeline would cause the total number of jobs to exceed the limit, the pipeline
|
||||
will fail with a `job_activity_limit_exceeded` error.
|
||||
fails with a `job_activity_limit_exceeded` error.
|
||||
|
||||
- GitLab SaaS subscribers have different limits [defined per plan](../user/gitlab_com/index.md#gitlab-cicd),
|
||||
and they affect all projects under that plan.
|
||||
|
@ -367,7 +367,7 @@ The total number of subscriptions can be limited per project. This limit is
|
|||
checked each time a new subscription is created.
|
||||
|
||||
If a new subscription would cause the total number of subscription to exceed the
|
||||
limit, the subscription will be considered invalid.
|
||||
limit, the subscription is considered invalid.
|
||||
|
||||
- GitLab SaaS subscribers have different limits [defined per plan](../user/gitlab_com/index.md#gitlab-cicd),
|
||||
and they affect all projects under that plan.
|
||||
|
@ -391,7 +391,7 @@ Set the limit to `0` to disable it.
|
|||
The total number of pipeline schedules can be limited per project. This limit is
|
||||
checked each time a new pipeline schedule is created. If a new pipeline schedule
|
||||
would cause the total number of pipeline schedules to exceed the limit, the
|
||||
pipeline schedule will not be created.
|
||||
pipeline schedule is not created.
|
||||
|
||||
GitLab SaaS subscribers have different limits [defined per plan](../user/gitlab_com/index.md#gitlab-cicd),
|
||||
and they affect all projects under that plan.
|
||||
|
@ -413,7 +413,7 @@ Plan.default.actual_limits.update!(ci_pipeline_schedules: 100)
|
|||
|
||||
The total number of instance level CI/CD variables is limited at the instance level.
|
||||
This limit is checked each time a new instance level variable is created. If a new variable
|
||||
would cause the total number of variables to exceed the limit, the new variable will not be created.
|
||||
would cause the total number of variables to exceed the limit, the new variable is created.
|
||||
|
||||
On self-managed instances this limit is defined for the `default` plan. By default,
|
||||
this limit is set to `25`.
|
||||
|
@ -607,8 +607,8 @@ Reports that go over the 20 MB limit won't be loaded. Affected reports:
|
|||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/8638) in GitLab 13.3.
|
||||
|
||||
You can set a limit on the content of repository files that are indexed in
|
||||
Elasticsearch. Any files larger than this limit will not be indexed, and thus
|
||||
will not be searchable.
|
||||
Elasticsearch. Any files larger than this limit is neither indexed
|
||||
nor searchable.
|
||||
|
||||
Setting a limit helps reduce the memory usage of the indexing processes and
|
||||
the overall index size. This value defaults to `1024 KiB` (1 MiB) as any
|
||||
|
@ -616,8 +616,8 @@ text files larger than this likely aren't meant to be read by humans.
|
|||
|
||||
You must set a limit, as unlimited file sizes aren't supported. Setting this
|
||||
value to be greater than the amount of memory on GitLab Sidekiq nodes causes
|
||||
the GitLab Sidekiq nodes to run out of memory, as they will pre-allocate this
|
||||
amount of memory during indexing.
|
||||
the GitLab Sidekiq nodes to run out of memory, as this amount of memory
|
||||
is pre-allocated during indexing.
|
||||
|
||||
### Maximum field length
|
||||
|
||||
|
@ -670,7 +670,7 @@ More information can be found in these docs:
|
|||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/31007) in GitLab 12.4.
|
||||
|
||||
Total number of changes (branches or tags) in a single push to determine whether
|
||||
individual push events or bulk push event will be created.
|
||||
individual push events or a bulk push event are created.
|
||||
|
||||
More information can be found in the [Push event activities limit and bulk push events documentation](../user/admin_area/settings/push_event_activities_limit.md).
|
||||
|
||||
|
|
|
@ -4,7 +4,7 @@ group: Configure
|
|||
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
|
||||
---
|
||||
|
||||
# Adding and removing Kubernetes clusters **(FREE)**
|
||||
# Add a cluster using cluster certificates **(FREE)**
|
||||
|
||||
GitLab offers integrated cluster creation for the following Kubernetes providers:
|
||||
|
||||
|
|
Loading…
Reference in New Issue