From 3f2ce963ab6f19c6f4c910406c0b06cf4772fc30 Mon Sep 17 00:00:00 2001 From: GitLab Bot Date: Mon, 14 Nov 2022 03:08:13 +0000 Subject: Add latest changes from gitlab-org/gitlab@master --- GITALY_SERVER_VERSION | 2 +- GITLAB_KAS_VERSION | 2 +- app/assets/stylesheets/page_bundles/ide.scss | 5 + app/finders/clusters/agent_tokens_finder.rb | 25 + ...500_add_vulnerability_reads_all_status_index.rb | 14 + db/schema_migrations/20221104170500 | 1 + db/structure.sql | 2 + doc/.vale/gitlab/spelling-exceptions.txt | 1 + doc/administration/gitaly/configure_gitaly.md | 15 - doc/administration/gitaly/index.md | 35 +- doc/administration/gitaly/praefect.md | 27 +- doc/administration/gitaly/recovery.md | 62 +- doc/administration/gitaly/troubleshooting.md | 28 +- .../output_example_snapshots/html.yml | 198 +- .../output_example_snapshots/snapshot_spec.html | 2846 ++++++++++---------- glfm_specification/output_spec/spec.html | 58 +- lib/api/clusters/agent_tokens.rb | 4 +- lib/banzai/filter/math_filter.rb | 9 +- lib/banzai/filter/syntax_highlight_filter.rb | 47 +- lib/banzai/pipeline/ascii_doc_pipeline.rb | 2 +- lib/banzai/pipeline/gfm_pipeline.rb | 4 +- spec/finders/clusters/agent_tokens_finder_spec.rb | 48 + .../markdown/markdown_golden_master_examples.yml | 14 +- spec/lib/banzai/filter/math_filter_spec.rb | 10 +- .../banzai/filter/syntax_highlight_filter_spec.rb | 43 +- spec/lib/gitlab/asciidoc_spec.rb | 19 +- spec/requests/api/clusters/agent_tokens_spec.rb | 12 +- spec/scripts/lib/glfm/update_specification_spec.rb | 12 +- workhorse/go.mod | 2 +- workhorse/go.sum | 4 +- 30 files changed, 1804 insertions(+), 1747 deletions(-) create mode 100644 app/finders/clusters/agent_tokens_finder.rb create mode 100644 db/post_migrate/20221104170500_add_vulnerability_reads_all_status_index.rb create mode 100644 db/schema_migrations/20221104170500 create mode 100644 spec/finders/clusters/agent_tokens_finder_spec.rb diff --git a/GITALY_SERVER_VERSION b/GITALY_SERVER_VERSION index 472fc034f84..331f653c3bc 100644 --- a/GITALY_SERVER_VERSION +++ b/GITALY_SERVER_VERSION @@ -1 +1 @@ -1ba70888404fcb9719d4eb33481f57138bce7447 +c952a9f6f75174ac933d5e964fae4e18c0f1fe65 diff --git a/GITLAB_KAS_VERSION b/GITLAB_KAS_VERSION index c85078ffaa1..9f6d8f2fdb4 100644 --- a/GITLAB_KAS_VERSION +++ b/GITLAB_KAS_VERSION @@ -1 +1 @@ -15.6.0-rc2 +15.6.0 diff --git a/app/assets/stylesheets/page_bundles/ide.scss b/app/assets/stylesheets/page_bundles/ide.scss index 3951f72112f..ec75c53d026 100644 --- a/app/assets/stylesheets/page_bundles/ide.scss +++ b/app/assets/stylesheets/page_bundles/ide.scss @@ -568,6 +568,11 @@ $ide-commit-header-height: 48px; text-decoration: line-through; } } + + .gl-form-radio, + .gl-form-checkbox { + color: var(--ide-text-color, $gl-text-color); + } } .ide-sidebar-link { diff --git a/app/finders/clusters/agent_tokens_finder.rb b/app/finders/clusters/agent_tokens_finder.rb new file mode 100644 index 00000000000..e241836e1dc --- /dev/null +++ b/app/finders/clusters/agent_tokens_finder.rb @@ -0,0 +1,25 @@ +# frozen_string_literal: true + +module Clusters + class AgentTokensFinder + def initialize(object, current_user, agent_id) + @object = object + @current_user = current_user + @agent_id = agent_id + end + + def execute + raise_not_found_unless_can_read_cluster + + object.cluster_agents.find(agent_id).agent_tokens + end + + private + + attr_reader :object, :current_user, :agent_id + + def raise_not_found_unless_can_read_cluster + raise ActiveRecord::RecordNotFound unless current_user&.can?(:read_cluster, object) + end + end +end diff --git a/db/post_migrate/20221104170500_add_vulnerability_reads_all_status_index.rb b/db/post_migrate/20221104170500_add_vulnerability_reads_all_status_index.rb new file mode 100644 index 00000000000..1dc1921ebaa --- /dev/null +++ b/db/post_migrate/20221104170500_add_vulnerability_reads_all_status_index.rb @@ -0,0 +1,14 @@ +# frozen_string_literal: true +class AddVulnerabilityReadsAllStatusIndex < Gitlab::Database::Migration[2.0] + INDEX_NAME = 'index_vulnerability_reads_on_namespace_type_severity_id' + + disable_ddl_transaction! + + def up + add_concurrent_index :vulnerability_reads, %i[namespace_id report_type severity vulnerability_id], name: INDEX_NAME + end + + def down + remove_concurrent_index_by_name :vulnerability_reads, INDEX_NAME + end +end diff --git a/db/schema_migrations/20221104170500 b/db/schema_migrations/20221104170500 new file mode 100644 index 00000000000..58fd45b5223 --- /dev/null +++ b/db/schema_migrations/20221104170500 @@ -0,0 +1 @@ +1826209494234355dd2014b3ae7f8ef5c2138a3d22ce143f744ab911e3ebb985 \ No newline at end of file diff --git a/db/structure.sql b/db/structure.sql index df56391c710..c80991c044d 100644 --- a/db/structure.sql +++ b/db/structure.sql @@ -31030,6 +31030,8 @@ CREATE INDEX index_vulnerability_reads_on_location_image ON vulnerability_reads CREATE INDEX index_vulnerability_reads_on_location_image_partial ON vulnerability_reads USING btree (project_id, location_image) WHERE ((report_type = ANY (ARRAY[2, 7])) AND (location_image IS NOT NULL)); +CREATE INDEX index_vulnerability_reads_on_namespace_type_severity_id ON vulnerability_reads USING btree (namespace_id, report_type, severity, vulnerability_id); + CREATE INDEX index_vulnerability_reads_on_scanner_id ON vulnerability_reads USING btree (scanner_id); CREATE UNIQUE INDEX index_vulnerability_reads_on_uuid ON vulnerability_reads USING btree (uuid); diff --git a/doc/.vale/gitlab/spelling-exceptions.txt b/doc/.vale/gitlab/spelling-exceptions.txt index 5d268fdb241..7d4806511af 100644 --- a/doc/.vale/gitlab/spelling-exceptions.txt +++ b/doc/.vale/gitlab/spelling-exceptions.txt @@ -546,6 +546,7 @@ relicensing remediations renderers replicables +rpcs repmgr repmgrd repurposing diff --git a/doc/administration/gitaly/configure_gitaly.md b/doc/administration/gitaly/configure_gitaly.md index ec3bb47dcb3..e7a6fc35ced 100644 --- a/doc/administration/gitaly/configure_gitaly.md +++ b/doc/administration/gitaly/configure_gitaly.md @@ -57,21 +57,6 @@ The process for setting up Gitaly on its own server is: 1. [Configure Gitaly clients](#configure-gitaly-clients). 1. [Disable Gitaly where not required](#disable-gitaly-where-not-required-optional) (optional). -When running Gitaly on its own server, note the following regarding GitLab versions: - -- From GitLab 11.4, Gitaly was able to serve all Git requests without requiring a shared NFS mount - for Git repository data, except for the - [Elasticsearch indexer](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer). -- From GitLab 11.8, the Elasticsearch indexer also uses Gitaly for data access. NFS can still be - leveraged for redundancy on block-level Git data, but should be mounted only on the Gitaly - servers. -- From GitLab 11.8 to 12.2, it is possible to use Elasticsearch in a Gitaly setup that doesn't use - NFS. To use Elasticsearch in these versions, the - [repository indexer](../../integration/advanced_search/elasticsearch.md#elasticsearch-repository-indexer) - must be enabled in your GitLab configuration. -- [In GitLab 12.3 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/6481), the new indexer is - the default and no configuration is required. - ### Network architecture The following list depicts the network architecture of Gitaly: diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md index 58a5da50fea..1b7e1f0f7c6 100644 --- a/doc/administration/gitaly/index.md +++ b/doc/administration/gitaly/index.md @@ -72,7 +72,8 @@ the current status of these issues, refer to the referenced issues and epics. |:--------------------------------------------------------------------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:--------------------------------| | Gitaly Cluster + Geo - Issues retrying failed syncs | If Gitaly Cluster is used on a Geo secondary site, repositories that have failed to sync could continue to fail when Geo tries to resync them. Recovering from this state requires assistance from support to run manual steps. | No known solution prior to GitLab 15.0. In GitLab 15.0 to 15.2, enable the [`gitaly_praefect_generated_replica_paths` feature flag](#praefect-generated-replica-paths-gitlab-150-and-later). In GitLab 15.3, the feature flag is enabled by default. | | Praefect unable to insert data into the database due to migrations not being applied after an upgrade | If the database is not kept up to date with completed migrations, then the Praefect node is unable to perform normal operation. | Make sure the Praefect database is up and running with all migrations completed (For example: `/opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml sql-migrate-status` should show a list of all applied migrations). Consider [requesting upgrade assistance](https://about.gitlab.com/support/scheduling-upgrade-assistance/) so your upgrade plan can be reviewed by support. | -| Restoring a Gitaly Cluster node from a snapshot in a running cluster | Because the Gitaly Cluster runs with consistent state, introducing a single node that is behind will result in the cluster not being able to reconcile the nodes data and other nodes data | Don't restore a single Gitaly Cluster node from a backup snapshot. If you must restore from backup, it's best to [shut down GitLab](../read_only_gitlab.md#shut-down-the-gitlab-ui), snapshot all Gitaly Cluster nodes at the same time and take a database dump of the Praefect database. | +| Restoring a Gitaly Cluster node from a snapshot in a running cluster | Because the Gitaly Cluster runs with consistent state, introducing a single node that is behind results in the cluster not being able to reconcile the nodes data and other nodes data | Don't restore a single Gitaly Cluster node from a backup snapshot. If you must restore from backup:

1. [Shut down GitLab](../read_only_gitlab.md#shut-down-the-gitlab-ui).
2. Snapshot all Gitaly Cluster nodes at the same time.
3. Take a database dump of the Praefect database. | +| Rebuilding or replacing an existing Gitaly Cluster node | There is no way to replace existing nodes in place because the Praefect database is relied on to determine the current state of each Gitaly node. Changing how Gitaly Cluster stores repositories is proposed in issue [4218](https://gitlab.com/gitlab-org/gitaly/-/issues/4218). Turning on [repository verification](praefect.md#repository-verification) is proposed in issue [4429](https://gitlab.com/gitlab-org/gitaly/-/issues/4429) so Praefect can detect that data is missing and needs to replicated to a new Gitaly node. | No known solution at this time. | ### Snapshot backup and recovery limitations @@ -467,12 +468,6 @@ including [horizontally distributing reads](https://gitlab.com/groups/gitlab-org #### Distributed reads -> - Introduced in GitLab 13.1 in [beta](../../policy/alpha-beta-support.md#beta-features) with feature flag `gitaly_distributed_reads` set to disabled. -> - [Made generally available and enabled by default](https://gitlab.com/gitlab-org/gitaly/-/issues/2951) in GitLab 13.3. -> - [Disabled by default](https://gitlab.com/gitlab-org/gitaly/-/issues/3178) in GitLab 13.5. -> - [Enabled by default](https://gitlab.com/gitlab-org/gitaly/-/issues/3334) in GitLab 13.8. -> - [Feature flag removed](https://gitlab.com/gitlab-org/gitaly/-/issues/3383) in GitLab 13.11. - Gitaly Cluster supports distribution of read operations across Gitaly nodes that are configured for the [virtual storage](#virtual-storage). @@ -493,31 +488,21 @@ You can [monitor distribution of reads](monitoring.md#monitor-gitaly-cluster) us #### Strong consistency -> - Introduced in GitLab 13.1 in [alpha](../../policy/alpha-beta-support.md#alpha-features), disabled by default. -> - Entered [beta](../../policy/alpha-beta-support.md#beta-features) in GitLab 13.2, disabled by default. -> - In GitLab 13.3, disabled unless primary-wins voting strategy is disabled. -> - From GitLab 13.4, enabled by default. -> - From GitLab 13.5, you must use Git v2.28.0 or higher on Gitaly nodes to enable strong consistency. -> - From GitLab 13.6, primary-wins voting strategy and the `gitaly_reference_transactions_primary_wins` feature flag was removed. -> - From GitLab 14.0, [Gitaly Cluster only supports strong consistency](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/3575), and the `gitaly_reference_transactions` feature flag was removed. +> - In GitLab 13.6 to 13.12, strong consistency must be manually configured. Refer to [the 13.12 documentation](https://docs.gitlab.com/13.12/ee/administration/gitaly/praefect.html#strong-consistency). +> - In GitLab 14.0, strong consistency is the primary replication method. Gitaly Cluster provides strong consistency by writing changes synchronously to all healthy, up-to-date replicas. If a replica is outdated or unhealthy at the time of the transaction, the write is asynchronously replicated to it. +Strong consistency is the primary replication method. A subset of operations still use replication jobs +(eventual consistency) instead of strong consistency. Refer to the +[strong consistency epic](https://gitlab.com/groups/gitlab-org/-/epics/1189) for more information. + If strong consistency is unavailable, Gitaly Cluster guarantees eventual consistency. In this case. Gitaly Cluster replicates all writes to secondary Gitaly nodes after the write to the primary Gitaly node has occurred. -Strong consistency: - -- Is the primary replication method in GitLab 14.0 and later. A subset of operations still use replication jobs - (eventual consistency) instead of strong consistency. Refer to the - [strong consistency epic](https://gitlab.com/groups/gitlab-org/-/epics/1189) for more information. -- Must be configured in GitLab versions 13.1 to 13.12. For configuration information, refer to either: - - Documentation on your GitLab instance at `/help`. - - The [13.12 documentation](https://docs.gitlab.com/13.12/ee/administration/gitaly/praefect.html#strong-consistency). -- Is unavailable in GitLab 13.0 and earlier. - -For more information on monitoring strong consistency, see the Gitaly Cluster [Prometheus metrics documentation](monitoring.md#monitor-gitaly-cluster). +For more information on monitoring strong consistency, see the Gitaly Cluster +[Prometheus metrics documentation](monitoring.md#monitor-gitaly-cluster). #### Replication factor diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md index 6e8450a8883..8cf32a6aaa3 100644 --- a/doc/administration/gitaly/praefect.md +++ b/doc/administration/gitaly/praefect.md @@ -595,11 +595,7 @@ Updates to example must be made at: } ``` - NOTE: - In [GitLab 13.8 and earlier](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4988), - Gitaly nodes were configured directly under the virtual storage, and not under the `nodes` key. - -1. [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2013) in GitLab 13.1 and later, enable [distribution of reads](index.md#distributed-reads). +1. Enable [distribution of reads](index.md#distributed-reads). 1. Save the changes to `/etc/gitlab/gitlab.rb` and [reconfigure Praefect](../restart_gitlab.md#omnibus-gitlab-reconfigure): @@ -652,8 +648,6 @@ Updates to example must be made at: #### Enable TLS support -> [Introduced](https://gitlab.com/gitlab-org/gitaly/-/issues/1698) in GitLab 13.2. - Praefect supports TLS encryption. To communicate with a Praefect instance that listens for secure connections, you must: @@ -1380,7 +1374,8 @@ We recommend using [repository-specific primary nodes](#repository-specific-prim ### Repository-specific primary nodes -> [Introduced](https://gitlab.com/gitlab-org/gitaly/-/issues/3492) in GitLab 13.12. +> - [Introduced](https://gitlab.com/gitlab-org/gitaly/-/issues/3492) in GitLab 13.12, with primary elections run when Praefect starts or the cluster's consensus of a Gitaly node's health changes. +> - [Changed](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/3543) in GitLab 14.1, primary elections are run lazily. Gitaly Cluster supports electing repository-specific primary Gitaly nodes. Repository-specific Gitaly primary nodes are enabled in `/etc/gitlab/gitlab.rb` by setting @@ -1397,14 +1392,8 @@ The `per_repository` election strategy solves this problem by electing a primary repository. Combined with [configurable replication factors](#configure-replication-factor), you can horizontally scale storage capacity and distribute write load across Gitaly nodes. -Primary elections are run: - -- In GitLab 14.1 and later, lazily. This means that Praefect doesn't immediately elect - a new primary node if the current one is unhealthy. A new primary is elected if it is - necessary to serve a request while the current primary is unavailable. -- In GitLab 13.12 to GitLab 14.0 when: - - Praefect starts up. - - The cluster's consensus of a Gitaly node's health changes. +Primary elections are run lazily. Praefect doesn't immediately elect a new primary node if the current +one is unhealthy. A new primary is elected if a request must be served while the current primary is unavailable. A valid primary node candidate is a Gitaly node that: @@ -1433,9 +1422,9 @@ To migrate existing clusters: 1. Praefect nodes didn't historically keep database records of every repository stored on the cluster. When the `per_repository` election strategy is configured, Praefect expects to have database records of - each repository. A [background database migration](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/2749) is - included in GitLab 13.6 and later to create any missing database records for repositories. Before migrating, - check Praefect's logs to verify that the database migration ran. + each repository. A [background database migration](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/2749) + creates any missing database records for repositories. Before migrating, check Praefect's logs to verify + that the database migration ran. Check Praefect's logs for `repository importer finished` message. The `virtual_storages` field contains the names of virtual storages and whether they've had any missing database records created. diff --git a/doc/administration/gitaly/recovery.md b/doc/administration/gitaly/recovery.md index b51454aa44e..56894f3e963 100644 --- a/doc/administration/gitaly/recovery.md +++ b/doc/administration/gitaly/recovery.md @@ -11,40 +11,15 @@ recovery and has Praefect tracking database tools. ## Primary node failure -Gitaly Cluster recovers from a failing primary Gitaly node by promoting a healthy secondary as the -new primary. +> - Introduced in GitLab 13.0, Gitaly Cluster, elects the secondary with the least unreplicated writes from the primary to be the new primary. There can still be some unreplicated writes, so [data loss can occur](#check-for-data-loss). +> - Primary node failure recovery support added in GitLab 14.1. -In GitLab 14.1 and later, Gitaly Cluster: +Gitaly Cluster recovers from a failing primary Gitaly node by promoting a healthy secondary as the new primary. Gitaly +Cluster: - Elects a healthy secondary with a fully up to date copy of the repository as the new primary. - Repository becomes unavailable if there are no fully up to date copies of it on healthy secondaries. -To minimize data loss in GitLab 13.0 to 14.0, Gitaly Cluster: - -- Switches repositories that are outdated on the new primary to [read-only mode](#read-only-mode). -- Elects the secondary with the least unreplicated writes from the primary to be the new - primary. Because there can still be some unreplicated writes, - [data loss can occur](#check-for-data-loss). - -### Read-only mode - -> - Introduced in GitLab 13.0 as [generally available](../../policy/alpha-beta-support.md#generally-available-ga). -> - Between GitLab 13.0 and GitLab 13.2, read-only mode applied to the whole virtual storage and occurred whenever failover occurred. -> - [In GitLab 13.3 and later](https://gitlab.com/gitlab-org/gitaly/-/issues/2862), read-only mode applies on a per-repository basis and only occurs if a new primary is out of date. If the failed primary contained unreplicated writes, [data loss can occur](#check-for-data-loss). -> - Removed in GitLab 14.1. Instead, repositories [become unavailable](#unavailable-repositories). - -When Gitaly Cluster switches to a new primary in GitLab 13.0 to 14.0, repositories enter read-only mode if they are -out-of-date. This can happen after failing over to an outdated secondary. Read-only mode eases data recovery efforts by -preventing writes that may conflict with the unreplicated writes on other nodes. - -To enable writes again in GitLab 13.0 to 14.0, an administrator can: - -1. [Check](#check-for-data-loss) for data loss. -1. Attempt to [recover](#data-recovery) missing data. -1. Either [enable writes](#enable-writes-or-accept-data-loss) in the virtual storage or - [accept data loss](#enable-writes-or-accept-data-loss) if necessary, depending on the version of - GitLab. - ### Unavailable repositories > - From GitLab 13.0 through 14.0, repositories became read-only if they were outdated on the primary but fully up to date on a healthy secondary. `dataloss` sub-command displays read-only repositories by default through these versions. @@ -144,9 +119,7 @@ Virtual storage: default #### Unavailable replicas of available repositories -NOTE: -In GitLab 14.0 and earlier, the flag is `-partially-replicated` and the output shows any repositories with assigned nodes with outdated -copies. +> Introduced in GitLab 14.0, flag renamed from `-partially-replicated` and behavior changed. To also list information of repositories which are available but are unavailable from some of the assigned nodes, use the `-partially-unavailable` flag. @@ -209,26 +182,17 @@ WARNING: `accept-dataloss` causes permanent data loss by overwriting other versions of the repository. Data [recovery efforts](#data-recovery) must be performed before using it. -Praefect provides the following subcommands to re-enable writes or accept data loss: - -- In GitLab 13.2 and earlier, `enable-writes` to re-enable virtual storage for writes after - data recovery attempts: +Praefect provides the following subcommands to re-enable writes or accept data loss. If it is not possible to bring one +of the up-to-date nodes back online, you might have to accept data loss: - ```shell - sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml enable-writes -virtual-storage - ``` - -- In GitLab 13.3 and later, if it is not possible to bring one of the up to date nodes back - online, you may have to accept data loss: - - ```shell - sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml accept-dataloss -virtual-storage -repository -authoritative-storage - ``` +```shell +sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml accept-dataloss -virtual-storage -repository -authoritative-storage +``` - When accepting data loss, Praefect: +When accepting data loss, Praefect: - 1. Marks the chosen copy of the repository as the latest version. - 1. Replicates the copy to the other assigned Gitaly nodes. +1. Marks the chosen copy of the repository as the latest version. +1. Replicates the copy to the other assigned Gitaly nodes. This process overwrites any other copy of the repository so care must be taken. diff --git a/doc/administration/gitaly/troubleshooting.md b/doc/administration/gitaly/troubleshooting.md index b8cbc9855c4..7edce840396 100644 --- a/doc/administration/gitaly/troubleshooting.md +++ b/doc/administration/gitaly/troubleshooting.md @@ -41,17 +41,6 @@ The `gitaly-debug` command provides "production debugging" tools for Gitaly and performance. It is intended to help production engineers and support engineers investigate Gitaly performance problems. -If you're using GitLab 11.6 or newer, this tool should be installed on -your GitLab or Gitaly server already at `/opt/gitlab/embedded/bin/gitaly-debug`. -If you're investigating an older GitLab version you can compile this -tool offline and copy the executable to your server: - -```shell -git clone https://gitlab.com/gitlab-org/gitaly.git -cd cmd/gitaly-debug -GOOS=linux GOARCH=amd64 go build -o gitaly-debug -``` - To see the help page of `gitaly-debug` for a list of supported sub-commands, run: ```shell @@ -144,9 +133,8 @@ If you have Prometheus set up to scrape your Gitaly process, you can see request rates and error codes for individual RPCs in `gitaly-ruby` by querying `grpc_client_handled_total`. -- In theory, this metric does not differentiate between `gitaly-ruby` and other RPCs. -- In practice from GitLab 11.9, all gRPC calls made by Gitaly itself are internal calls from the - main Gitaly process to one of its `gitaly-ruby` sidecars. +All gRPC calls made by `gitaly-ruby` itself are internal calls from the main Gitaly process to one of its `gitaly-ruby` +sidecars. Assuming your `grpc_client_handled_total` counter only observes Gitaly, the following query shows you RPCs are (most likely) internally @@ -335,7 +323,7 @@ You might see the following in Gitaly and Praefect logs: } ``` -This is a GRPC call +This is a gRPC call [error response code](https://grpc.github.io/grpc/core/md_doc_statuscodes.html). If this error occurs, even though @@ -604,6 +592,16 @@ For each replica, the following metadata is available: | `Valid Primary` | Indicates whether the replica is fit to serve as the primary node. If the repository's primary is not a valid primary, a failover occurs on the next write to the repository if there is another replica that is a valid primary. A replica is a valid primary if:

- It is stored on a healthy Gitaly node.
- It is fully up to date.
- It is not targeted by a pending deletion job from decreasing replication factor.
- It is assigned. | | `Verified At` | Indicates last successful verification of the replica by the [verification worker](praefect.md#repository-verification). If the replica has not yet been verified, `unverified` is displayed in place of the last successful verification time. Introduced in GitLab 15.0. | +#### Command fails with 'repository not found' + +If the supplied value for `-virtual-storage` is incorrect, the command returns the following error: + +```plaintext +get metadata: rpc error: code = NotFound desc = repository not found +``` + +The documented examples specify `-virtual-storage default`. Check the Praefect server setting `praefect['virtual_storages']` in `/etc/gitlab/gitlab.rb`. + ### Check that repositories are in sync Is [some cases](index.md#known-issues) the Praefect database can get out of sync with the underlying Gitaly nodes. To check that diff --git a/glfm_specification/output_example_snapshots/html.yml b/glfm_specification/output_example_snapshots/html.yml index 69cff67d27d..a16ee2e7200 100644 --- a/glfm_specification/output_example_snapshots/html.yml +++ b/glfm_specification/output_example_snapshots/html.yml @@ -2,22 +2,22 @@ 02_01_00__preliminaries__tabs__001: canonical: "
foo\tbaz\t\tbim\n
\n" static: "
\n
foo\tbaz\t\tbim
\n\n
" wysiwyg: "
foo\tbaz\t\tbim
" 02_01_00__preliminaries__tabs__002: canonical: "
foo\tbaz\t\tbim\n
\n" static: "
\n
foo\tbaz\t\tbim
\n\n
" wysiwyg: "
foo\tbaz\t\tbim
" 02_01_00__preliminaries__tabs__003: canonical: "
a\ta\nὐ\ta\n
\n" static: "
\n
a\ta\nὐ\ta
\n\n
" wysiwyg: "
a\ta\nὐ\ta
" @@ -52,7 +52,7 @@

  • foo

    - 
      bar
    + 
      bar
    • @@ -68,7 +68,7 @@ static: |-
    - 
      foo
    + 
      foo
    @@ -86,7 +86,7 @@