diff options
| author | wojtekt <wojtekt@google.com> | 2019-10-17 10:07:14 +0200 |
|---|---|---|
| committer | wojtekt <wojtekt@google.com> | 2019-10-17 10:07:14 +0200 |
| commit | c07e3ce87dca23d885cb7cf61b2ae37b95554a1e (patch) | |
| tree | e810f7896e301c1ffa37b7582cce785daca24b96 | |
| parent | 16c085563b4f667e4e17bef2c930cfff67d6612f (diff) | |
Remove references to initializers in SLOs
| -rw-r--r-- | sig-scalability/slos/api_call_latency.md | 12 | ||||
| -rw-r--r-- | sig-scalability/slos/api_extensions_latency.md | 5 | ||||
| -rw-r--r-- | sig-scalability/slos/slos.md | 1 |
3 files changed, 8 insertions, 10 deletions
diff --git a/sig-scalability/slos/api_call_latency.md b/sig-scalability/slos/api_call_latency.md index 7e6b0785..45764f9c 100644 --- a/sig-scalability/slos/api_call_latency.md +++ b/sig-scalability/slos/api_call_latency.md @@ -27,15 +27,15 @@ namespaces. - As a user of vanilla Kubernetes, I want some guarantee how quickly I get the response from an API call. - As an administrator of Kubernetes cluster, if I know characteristics of my -external dependencies of apiserver (e.g custom admission plugins, webhooks and -initializers) I want to be able to provide guarantees for API calls latency to -users of my cluster. +external dependencies of apiserver (e.g custom admission plugins and webhooks) +I want to be able to provide guarantees for API calls latency to users of my +cluster. ### Other notes - We obviously can’t give any guarantee in general, because cluster -administrators are allowed to register custom admission plugins, webhooks -and/or initializers, which we don’t have any control about and they obviously -impact API call latencies. +administrators are allowed to register custom admission plugins or webhooks, +which we don’t have any control about and they obviously impact API call +latencies. - As a result, we define the SLIs to be very generic (no matter how your cluster is set up), but we provide SLO only for default installations (where we have control over what apiserver is doing). This doesn’t provide a false diff --git a/sig-scalability/slos/api_extensions_latency.md b/sig-scalability/slos/api_extensions_latency.md index c5490ec1..5c801304 100644 --- a/sig-scalability/slos/api_extensions_latency.md +++ b/sig-scalability/slos/api_extensions_latency.md @@ -6,9 +6,8 @@ | --- | --- | | WIP | Admission latency for each admission plugin type, measured as 99th percentile over last 5 minutes | | WIP | Webhook call latency for each webhook type, measured as 99th percentile over last 5 minutes -| WIP | Initializer latency for each initializer, measured as 99th percentile over last 5 minutes | ### User stories - As an administrator, if API calls are slow, I would like to know if this is -because slow extension points (admission plugins, webhooks, initializers) and -if so which ones are responsible for it. +because slow extension points (admission plugins, webhooks) and if so which ones +are responsible for it. diff --git a/sig-scalability/slos/slos.md b/sig-scalability/slos/slos.md index fe3bda43..0cdb576b 100644 --- a/sig-scalability/slos/slos.md +++ b/sig-scalability/slos/slos.md @@ -135,5 +135,4 @@ sliding window. However, for the purpose of SLO itself, it basically means | WIP | Watch latency for every resource, (from the moment when object is stored in database to when it's ready to be sent to all watchers), measured as 99th percentile over last 5 minutes | [Details](./watch_latency.md) | | WIP | Admission latency for each admission plugin type, measured as 99th percentile over last 5 minutes | [Details](./api_extensions_latency.md) | | WIP | Webhook call latency for each webhook type, measured as 99th percentile over last 5 minutes | [Details](./api_extensions_latency.md) | -| WIP | Initializer latency for each initializer, measured as 99th percentile over last 5 minutes | [Details](./api_extensions_latency.md) | |