diff options
| author | Grzegorz Bizon <grzegorz@gitlab.com> | 2018-07-06 11:38:07 +0000 |
|---|---|---|
| committer | Grzegorz Bizon <grzegorz@gitlab.com> | 2018-07-06 11:38:07 +0000 |
| commit | 9c720a98b9fc7a3cc35b019251c5285378c9ae18 (patch) | |
| tree | ffe7b38f4476528a91443e889235355402471f54 /doc | |
| parent | bf9fd9c3fc3ded123458093efdcdae33f083300d (diff) | |
| parent | 21399fbc31083dce37a37980668c408520a136e0 (diff) | |
| download | gitlab-ce-9c720a98b9fc7a3cc35b019251c5285378c9ae18.tar.gz | |
Merge branch 'build-chunks-on-object-storage' into 'master'
Allow to store BuildTraceChunks on Object Storage
Closes #45712
See merge request gitlab-org/gitlab-ce!19515
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/administration/job_traces.md | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/doc/administration/job_traces.md b/doc/administration/job_traces.md index f1c5b194f4c..24d1a3fd151 100644 --- a/doc/administration/job_traces.md +++ b/doc/administration/job_traces.md @@ -77,10 +77,10 @@ cloud-native, for example on Kubernetes. The data flow is the same as described in the [data flow section](#data-flow) with one change: _the stored path of the first two phases is different_. This new live -trace architecture stores chunks of traces in Redis and the database instead of +trace architecture stores chunks of traces in Redis and a persistent store (object storage or database) instead of file storage. Redis is used as first-class storage, and it stores up-to 128KB -of data. Once the full chunk is sent, it is flushed to database. After a while, -the data in Redis and database will be archived to [object storage](#uploading-traces-to-object-storage). +of data. Once the full chunk is sent, it is flushed a persistent store, either object storage(temporary directory) or database. +After a while, the data in Redis and a persitent store will be archived to [object storage](#uploading-traces-to-object-storage). The data are stored in the following Redis namespace: `Gitlab::Redis::SharedState`. @@ -89,11 +89,11 @@ Here is the detailed data flow: 1. GitLab Runner picks a job from GitLab 1. GitLab Runner sends a piece of trace to GitLab 1. GitLab appends the data to Redis -1. Once the data in Redis reach 128KB, the data is flushed to the database. +1. Once the data in Redis reach 128KB, the data is flushed to a persistent store (object storage or the database). 1. The above steps are repeated until the job is finished. 1. Once the job is finished, GitLab schedules a Sidekiq worker to archive the trace. 1. The Sidekiq worker archives the trace to object storage and cleans up the trace - in Redis and the database. + in Redis and a persistent store (object storage or the database). ### Enabling live trace |