From f99704a490d2cbf86e76ee8f8b1f17c0c7e7e75f Mon Sep 17 00:00:00 2001 From: likeXXxx Date: Mon, 29 Oct 2018 13:50:23 +0800 Subject: [PATCH] fix some typos (#2867) * fix a type * fix a typo * fix a typo * fix a typo --- sig-architecture/api-review-process.md | 2 +- sig-scalability/slos/network_programming_latency.md | 2 +- sig-scalability/slos/pod_startup_latency.md | 2 +- sig-scalability/slos/slos.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/sig-architecture/api-review-process.md b/sig-architecture/api-review-process.md index a7c281c0be7..989de05f6ae 100644 --- a/sig-architecture/api-review-process.md +++ b/sig-architecture/api-review-process.md @@ -20,7 +20,7 @@ Because expert reviewer bandwidth is extremely limited, the process provides a c * Maintain the high standards of the project, including positive user interactions with APIs -* Provide review regardless of method of API defininition (built-in, Extension API Server, or Custom Resource Definition) +* Provide review regardless of method of API definition (built-in, Extension API Server, or Custom Resource Definition) * Provide review over both tightly coupled external projects and in-tree API changes. diff --git a/sig-scalability/slos/network_programming_latency.md b/sig-scalability/slos/network_programming_latency.md index 38eeebf0c4d..dc1dace20c5 100644 --- a/sig-scalability/slos/network_programming_latency.md +++ b/sig-scalability/slos/network_programming_latency.md @@ -60,7 +60,7 @@ this update: already present at storage layer, so it won't be hard to propagate that. 1. The in-cluster load-balancing programmer will export a prometheus metric once done with programming. The latency of the operation is defined as -difference betweem timestamp of then whe operation is done and timestamp +difference between timestamp of then whe operation is done and timestamp recorded in the newly introduced annotation. #### Caveats diff --git a/sig-scalability/slos/pod_startup_latency.md b/sig-scalability/slos/pod_startup_latency.md index 04fdd63b010..7c52777ee3e 100644 --- a/sig-scalability/slos/pod_startup_latency.md +++ b/sig-scalability/slos/pod_startup_latency.md @@ -38,7 +38,7 @@ is heavily application-dependent (and does't depend on Kubernetes itself). not obvious. We decided for the semantic of "when all its containers are reported as started and observed via watch", because: - we require all containers to be started (not e.g. the first one) to ensure - that the pod is started. We need to ensure that pontential regressions like + that the pod is started. We need to ensure that potential regressions like linearization of container startups within a pod will be catch by this SLI. - note that we don't require all container to be running - if some of them finished before the last one was started that is also fine. It is just diff --git a/sig-scalability/slos/slos.md b/sig-scalability/slos/slos.md index 5b9fb4bff77..1f9a15c827b 100644 --- a/sig-scalability/slos/slos.md +++ b/sig-scalability/slos/slos.md @@ -27,7 +27,7 @@ Our SLIs/SLOs need to have the following properties: arcane knowledge. We may also introduce internal(for developers only) SLIs, that may be useful -for understanding performance characterstic of the system, but for which +for understanding performance characteristic of the system, but for which we don't provide any guarantees for users (and thus don't require them to be that easily understandable).