Remove references to initializers in SLOs

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

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.

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) |