diff options
Diffstat (limited to 'doc/architecture')
4 files changed, 10 insertions, 10 deletions
diff --git a/doc/architecture/blueprints/cells/routing-service.md b/doc/architecture/blueprints/cells/routing-service.md index 2b4fa88f187..bd5570b68f4 100644 --- a/doc/architecture/blueprints/cells/routing-service.md +++ b/doc/architecture/blueprints/cells/routing-service.md @@ -378,7 +378,7 @@ Each Cell does implement classification endpoint: requests for sharding keys that are not found. - The cached response is for time defined by `expiry` and `refresh`. - The `expiry` defines when the item is removed from cache unless used. - - The `refresh` defines when the item needs to be reclassified if used. + - The `refresh` defines when the item needs to be reclassified if used. - The refresh is done asynchronously as the request should be served without a delay if they were classified. The refresh is done to ensure that cache is always hot and up-to date. For the above example: diff --git a/doc/architecture/blueprints/runner_admission_controller/index.md b/doc/architecture/blueprints/runner_admission_controller/index.md index 21dc1d53303..0a62b271901 100644 --- a/doc/architecture/blueprints/runner_admission_controller/index.md +++ b/doc/architecture/blueprints/runner_admission_controller/index.md @@ -140,7 +140,7 @@ Each runner has a tag identifier unique to that runner, e.g. `DiscoveryOne`, `tu 1. The `preparing` state will wait for a response from the webhook or until timeout. 1. The UI should be updated with the current status of the job prerequisites and admission 1. For jobs where the webhook times out (1 hour) their status should be set as though the admission was denied with a timeout reasoning. This should -be rare in typical circumstances. + be rare in typical circumstances. 1. Jobs with denied admission can be retried. Retried jobs will be resent to the admission controller without tag mutations or runner filtering reset. 1. [`allow_failure`](../../../ci/yaml/index.md#allow_failure) should be updated to support jobs that fail on denied admissions, for example: diff --git a/doc/architecture/blueprints/runner_tokens/index.md b/doc/architecture/blueprints/runner_tokens/index.md index f2e9d624d20..c667a460f5c 100644 --- a/doc/architecture/blueprints/runner_tokens/index.md +++ b/doc/architecture/blueprints/runner_tokens/index.md @@ -284,11 +284,11 @@ not an issue per-se. New records are created in 2 situations: -- when the runner calls the `POST /api/v4/runners/verify` endpoint as part of the -`gitlab-runner register` command, if the specified runner token is prefixed with `glrt-`. -This allows the frontend to determine whether the user has successfully completed the registration and take an -appropriate action; -- when GitLab is pinged for new jobs and a record matching the `token`+`system_id` does not already exist. +- When the runner calls the `POST /api/v4/runners/verify` endpoint as part of the + `gitlab-runner register` command, if the specified runner token is prefixed with `glrt-`. + This allows the frontend to determine whether the user has successfully completed the registration and take an + appropriate action; +- When GitLab is pinged for new jobs and a record matching the `token`+`system_id` does not already exist. Due to the time-decaying nature of the `ci_runner_machines` records, they are automatically cleaned after 7 days after the last contact from the respective runner. diff --git a/doc/architecture/blueprints/secret_manager/index.md b/doc/architecture/blueprints/secret_manager/index.md index ac30f3399d8..3a538f58dde 100644 --- a/doc/architecture/blueprints/secret_manager/index.md +++ b/doc/architecture/blueprints/secret_manager/index.md @@ -114,10 +114,10 @@ the data keys mentioned above. ### Further investigations required 1. Management of identities stored in GCP Key Management. -We need to investigate how we can correlate and de-multiplex GitLab identities into -GCP identities that are used to allow access to cryptographic operations on GCP Key Management. + We need to investigate how we can correlate and de-multiplex GitLab identities into + GCP identities that are used to allow access to cryptographic operations on GCP Key Management. 1. Authentication of clients. Clients to the Secrets Manager could be GitLab Runner or external clients. -For each of these, we need a secure and reliable method to authenticate requests to decrypt a secret. + For each of these, we need a secure and reliable method to authenticate requests to decrypt a secret. 1. Assignment of GCP backed private keys to each identity. ### Availability on SaaS and Self-Managed |