diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-11-19 11:27:35 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-11-19 11:27:35 +0300 |
commit | 7e9c479f7de77702622631cff2628a9c8dcbc627 (patch) | |
tree | c8f718a08e110ad7e1894510980d2155a6549197 /doc/development/chaos_endpoints.md | |
parent | e852b0ae16db4052c1c567d9efa4facc81146e88 (diff) |
Add latest changes from gitlab-org/gitlab@13-6-stable-eev13.6.0-rc42
Diffstat (limited to 'doc/development/chaos_endpoints.md')
-rw-r--r-- | doc/development/chaos_endpoints.md | 19 |
1 files changed, 12 insertions, 7 deletions
diff --git a/doc/development/chaos_endpoints.md b/doc/development/chaos_endpoints.md index 26ff3d2def7..63218af857d 100644 --- a/doc/development/chaos_endpoints.md +++ b/doc/development/chaos_endpoints.md @@ -1,3 +1,9 @@ +--- +stage: none +group: unassigned +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/#designated-technical-writers +--- + # Generating chaos in a test GitLab instance As [Werner Vogels](https://twitter.com/Werner), the CTO at Amazon Web Services, famously put it, **Everything fails, all the time**. @@ -18,7 +24,7 @@ Currently, there are four endpoints for simulating the following conditions: For obvious reasons, these endpoints are not enabled by default on `production`. They are enabled by default on **development** environments. -DANGER: **Danger:** +DANGER: **Warning:** It is required that you secure access to the chaos endpoints using a secret token. You should not enable them in production unless you absolutely know what you're doing. @@ -44,8 +50,7 @@ each endpoint can be set to `true`. This will run the chaos process in a Sidekiq To simulate a memory leak in your application, use the `/-/chaos/leakmem` endpoint. -NOTE: **Note:** -The memory is not retained after the request finishes. Once the request has completed, the Ruby garbage collector will attempt to recover the memory. +The memory is not retained after the request finishes. After the request has completed, the Ruby garbage collector will attempt to recover the memory. ```plaintext GET /-/chaos/leakmem @@ -80,7 +85,7 @@ GET /-/chaos/cpu_spin?duration_s=50&async=true | Attribute | Type | Required | Description | | ------------ | ------- | -------- | --------------------------------------------------------------------- | -| `duration_s` | integer | no | Duration, in seconds, that the core will be utilized. Defaults to 30s | +| `duration_s` | integer | no | Duration, in seconds, that the core will be used. Defaults to 30s | | `async` | boolean | no | Set to true to consume CPU in a Sidekiq background worker process | ```shell @@ -105,7 +110,7 @@ GET /-/chaos/db_spin?duration_s=50&async=true | Attribute | Type | Required | Description | | ------------ | ------- | -------- | --------------------------------------------------------------------------- | | `interval_s` | float | no | Interval, in seconds, for every DB request. Defaults to 1s | -| `duration_s` | integer | no | Duration, in seconds, that the core will be utilized. Defaults to 30s | +| `duration_s` | integer | no | Duration, in seconds, that the core will be used. Defaults to 30s | | `async` | boolean | no | Set to true to perform the operation in a Sidekiq background worker process | ```shell @@ -139,8 +144,8 @@ curl http://localhost:3000/-/chaos/sleep?duration_s=60&token=secret This endpoint will simulate the unexpected death of a worker process using a `kill` signal. -NOTE: **Note:** -Since this endpoint uses the `KILL` signal, the worker is not given a chance to cleanup or shutdown. +Because this endpoint uses the `KILL` signal, the worker isn't given an +opportunity to cleanup or shutdown. ```plaintext GET /-/chaos/kill |