kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

fix some typos (#2867) 

* fix a type

* fix a typo

* fix a typo

* fix a typo
This commit is contained in:
likeXXxx 2018-10-29 13:50:23 +08:00 committed by k8s-ci-robot
parent 38d96e9eaa
commit f99704a490
4 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
sig-architecture/api-review-process.md
View File

@ -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 * 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. * Provide review over both tightly coupled external projects and in-tree API changes.

2
sig-scalability/slos/network_programming_latency.md
View File

@ -60,7 +60,7 @@ this update:
already present at storage layer, so it won't be hard to propagate that. 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 1. The in-cluster load-balancing programmer will export a prometheus metric
once done with programming. The latency of the operation is defined as 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. recorded in the newly introduced annotation.
#### Caveats #### Caveats

2
sig-scalability/slos/pod_startup_latency.md
View File

@ -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 not obvious. We decided for the semantic of "when all its containers are
reported as started and observed via watch", because: reported as started and observed via watch", because:
- we require all containers to be started (not e.g. the first one) to ensure - 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. 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 - 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 finished before the last one was started that is also fine. It is just

2
sig-scalability/slos/slos.md
View File

@ -27,7 +27,7 @@ Our SLIs/SLOs need to have the following properties:
arcane knowledge. arcane knowledge.
We may also introduce internal(for developers only) SLIs, that may be useful 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 we don't provide any guarantees for users (and thus don't require them to be
that easily understandable). that easily understandable).