diff options
author | Evan Read <eread@gitlab.com> | 2018-11-13 09:07:16 +0300 |
---|---|---|
committer | Evan Read <eread@gitlab.com> | 2019-01-08 05:21:09 +0300 |
commit | d98560c1f5c54127d1a48c4c8e326bbf06c31c4b (patch) | |
tree | b2d2fc26829e0a7b25da18d09a1e7e07ba1efed8 /doc/administration | |
parent | 710f2ec50c49d1e773acc20058ed584f1402de33 (diff) |
Make unordered lists conform to styleguide
- Also makes other minor Markdown fixes that were near the main fixes.
Diffstat (limited to 'doc/administration')
-rw-r--r-- | doc/administration/high_availability/redis.md | 8 | ||||
-rw-r--r-- | doc/administration/high_availability/redis_source.md | 8 | ||||
-rw-r--r-- | doc/administration/housekeeping.md | 19 | ||||
-rw-r--r-- | doc/administration/integration/terminal.md | 26 | ||||
-rw-r--r-- | doc/administration/raketasks/check.md | 6 | ||||
-rw-r--r-- | doc/administration/repository_storage_types.md | 4 | ||||
-rw-r--r-- | doc/administration/troubleshooting/debug.md | 4 |
7 files changed, 37 insertions, 38 deletions
diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md index 833c1f367dd..987a0b9f350 100644 --- a/doc/administration/high_availability/redis.md +++ b/doc/administration/high_availability/redis.md @@ -545,10 +545,10 @@ discussed in [Redis setup overview](#redis-setup-overview) and Here is a list and description of each **machine** and the assigned **IP**: -* `10.0.0.1`: Redis Master + Sentinel 1 -* `10.0.0.2`: Redis Slave 1 + Sentinel 2 -* `10.0.0.3`: Redis Slave 2 + Sentinel 3 -* `10.0.0.4`: GitLab application +- `10.0.0.1`: Redis Master + Sentinel 1 +- `10.0.0.2`: Redis Slave 1 + Sentinel 2 +- `10.0.0.3`: Redis Slave 2 + Sentinel 3 +- `10.0.0.4`: GitLab application Please note that after the initial configuration, if a failover is initiated by the Sentinel nodes, the Redis nodes will be reconfigured and the **Master** diff --git a/doc/administration/high_availability/redis_source.md b/doc/administration/high_availability/redis_source.md index 2101d36d2b6..14e2784c419 100644 --- a/doc/administration/high_availability/redis_source.md +++ b/doc/administration/high_availability/redis_source.md @@ -214,10 +214,10 @@ For this example, **Sentinel 1** will be configured in the same machine as the Here is a list and description of each **machine** and the assigned **IP**: -* `10.0.0.1`: Redis Master + Sentinel 1 -* `10.0.0.2`: Redis Slave 1 + Sentinel 2 -* `10.0.0.3`: Redis Slave 2 + Sentinel 3 -* `10.0.0.4`: GitLab application +- `10.0.0.1`: Redis Master + Sentinel 1 +- `10.0.0.2`: Redis Slave 1 + Sentinel 2 +- `10.0.0.3`: Redis Slave 2 + Sentinel 3 +- `10.0.0.4`: GitLab application Please note that after the initial configuration, if a failover is initiated by the Sentinel nodes, the Redis nodes will be reconfigured and the **Master** diff --git a/doc/administration/housekeeping.md b/doc/administration/housekeeping.md index bb621b788f1..058346df56d 100644 --- a/doc/administration/housekeeping.md +++ b/doc/administration/housekeeping.md @@ -17,19 +17,18 @@ The housekeeping function will run a `repack` or `gc` depending on the For example in the following scenario a `git repack -d` will be executed: -+ Project: pushes since gc counter (`pushes_since_gc`) = `10` -+ Git GC period = `200` -+ Full repack period = `50` +- Project: pushes since gc counter (`pushes_since_gc`) = `10` +- Git GC period = `200` +- Full repack period = `50` When the `pushes_since_gc` value is 50 a `repack -A -d --pack-kept-objects` will run, similarly when the `pushes_since_gc` value is 200 a `git gc` will be run. -+ `git gc` ([man page][man-gc]) runs a number of housekeeping tasks, -such as compressing filerevisions (to reduce disk space and increase performance) -and removing unreachable objects which may have been created from prior invocations of -`git add`. - -+ `git repack` ([man page][man-repack]) re-organize existing packs into a single, more efficient pack. +- `git gc` ([man page][man-gc]) runs a number of housekeeping tasks, + such as compressing filerevisions (to reduce disk space and increase performance) + and removing unreachable objects which may have been created from prior invocations of + `git add`. +- `git repack` ([man page][man-repack]) re-organize existing packs into a single, more efficient pack. You can find this option under your **[Project] > Edit Project**. @@ -39,4 +38,4 @@ You can find this option under your **[Project] > Edit Project**. [ce-2371]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2371 "Housekeeping merge request" [man-gc]: https://www.kernel.org/pub/software/scm/git/docs/git-gc.html "git gc man page" -[man-repack]: https://www.kernel.org/pub/software/scm/git/docs/git-repack.html
\ No newline at end of file +[man-repack]: https://www.kernel.org/pub/software/scm/git/docs/git-repack.html diff --git a/doc/administration/integration/terminal.md b/doc/administration/integration/terminal.md index fa58d0ef15f..06ef6988014 100644 --- a/doc/administration/integration/terminal.md +++ b/doc/administration/integration/terminal.md @@ -14,17 +14,17 @@ A detailed overview of the architecture of web terminals and how they work can be found in [this document](https://gitlab.com/gitlab-org/gitlab-workhorse/blob/master/doc/terminal.md). In brief: -* GitLab relies on the user to provide their own Kubernetes credentials, and to +- GitLab relies on the user to provide their own Kubernetes credentials, and to appropriately label the pods they create when deploying. -* When a user navigates to the terminal page for an environment, they are served +- When a user navigates to the terminal page for an environment, they are served a JavaScript application that opens a WebSocket connection back to GitLab. -* The WebSocket is handled in [Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse), +- The WebSocket is handled in [Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse), rather than the Rails application server. -* Workhorse queries Rails for connection details and user permissions; Rails - queries Kubernetes for them in the background, using [Sidekiq](../troubleshooting/sidekiq.md) -* Workhorse acts as a proxy server between the user's browser and the Kubernetes +- Workhorse queries Rails for connection details and user permissions. Rails + queries Kubernetes for them in the background using [Sidekiq](../troubleshooting/sidekiq.md). +- Workhorse acts as a proxy server between the user's browser and the Kubernetes API, passing WebSocket frames between the two. -* Workhorse regularly polls Rails, terminating the WebSocket connection if the +- Workhorse regularly polls Rails, terminating the WebSocket connection if the user no longer has permission to access the terminal, or if the connection details have changed. @@ -40,10 +40,10 @@ However, if you run a [load balancer](../high_availability/load_balancer.md) in front of GitLab, you may need to make some changes to your configuration. These guides document the necessary steps for a selection of popular reverse proxies: -* [Apache](https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html) -* [NGINX](https://www.nginx.com/blog/websocket-nginx/) -* [HAProxy](http://blog.haproxy.com/2012/11/07/websockets-load-balancing-with-haproxy/) -* [Varnish](https://www.varnish-cache.org/docs/4.1/users-guide/vcl-example-websockets.html) +- [Apache](https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html) +- [NGINX](https://www.nginx.com/blog/websocket-nginx/) +- [HAProxy](http://blog.haproxy.com/2012/11/07/websockets-load-balancing-with-haproxy/) +- [Varnish](https://www.varnish-cache.org/docs/4.1/users-guide/vcl-example-websockets.html) Workhorse won't let WebSocket requests through to non-WebSocket endpoints, so it's safe to enable support for these headers globally. If you'd rather had a @@ -60,8 +60,8 @@ the `Connection` and `Upgrade` hop-by-hop headers in the *first* HTTP reverse proxy in the chain. For most users, this will be the NGINX server bundled with Omnibus GitLab, in which case, you need to: -* Find the `nginx['proxy_set_headers']` section of your `gitlab.rb` file -* Ensure the whole block is uncommented, and then comment out or remove the +- Find the `nginx['proxy_set_headers']` section of your `gitlab.rb` file +- Ensure the whole block is uncommented, and then comment out or remove the `Connection` and `Upgrade` lines. For your own load balancer, just reverse the configuration changes recommended diff --git a/doc/administration/raketasks/check.md b/doc/administration/raketasks/check.md index 0ca1d77f1d0..d8f80965c21 100644 --- a/doc/administration/raketasks/check.md +++ b/doc/administration/raketasks/check.md @@ -52,9 +52,9 @@ and these checks will verify them against current files. Currently, integrity checks are supported for the following types of file: -* CI artifacts (Available from version 10.7.0) -* LFS objects (Available from version 10.6.0) -* User uploads (Available from version 10.6.0) +- CI artifacts (Available from version 10.7.0) +- LFS objects (Available from version 10.6.0) +- User uploads (Available from version 10.6.0) **Omnibus Installation** diff --git a/doc/administration/repository_storage_types.md b/doc/administration/repository_storage_types.md index 12238ba7b32..51e1518d73f 100644 --- a/doc/administration/repository_storage_types.md +++ b/doc/administration/repository_storage_types.md @@ -7,8 +7,8 @@ Legacy Storage is the storage behavior prior to version 10.0. For historical reasons, GitLab replicated the same mapping structure from the projects URLs: -* Project's repository: `#{namespace}/#{project_name}.git` -* Project's wiki: `#{namespace}/#{project_name}.wiki.git` +- Project's repository: `#{namespace}/#{project_name}.git` +- Project's wiki: `#{namespace}/#{project_name}.wiki.git` This structure made it simple to migrate from existing solutions to GitLab and easy for Administrators to find where the repository is stored. diff --git a/doc/administration/troubleshooting/debug.md b/doc/administration/troubleshooting/debug.md index 643c5b9fe80..bd702dcc9ec 100644 --- a/doc/administration/troubleshooting/debug.md +++ b/doc/administration/troubleshooting/debug.md @@ -211,5 +211,5 @@ The output in `/tmp/unicorn.txt` may help diagnose the root cause. # More information -* [Debugging Stuck Ruby Processes](https://blog.newrelic.com/2013/04/29/debugging-stuck-ruby-processes-what-to-do-before-you-kill-9/) -* [Cheatsheet of using gdb and ruby processes](gdb-stuck-ruby.txt) +- [Debugging Stuck Ruby Processes](https://blog.newrelic.com/2013/04/29/debugging-stuck-ruby-processes-what-to-do-before-you-kill-9/) +- [Cheatsheet of using gdb and ruby processes](gdb-stuck-ruby.txt) |