Spelling fixes inspired by github.com/client9/misspell

This commit is contained in:
laushinka
2016-02-13 02:33:32 +07:00
parent 6435d03400
commit 7ef585be22
111 changed files with 152 additions and 152 deletions

View File

@@ -79,7 +79,7 @@ Guide](../admin/README.md).
Document style advice for contributors.
* **Running a cluster locally** ([running-locally.md](running-locally.md)):
A fast and lightweight local cluster deployment for developement.
A fast and lightweight local cluster deployment for development.
## Developing against the Kubernetes API

View File

@@ -306,7 +306,7 @@ removed value as deprecated but allowed). This is actually a special case of
a new representation, discussed above.
For [Unions](api-conventions.md), sets of fields where at most one should be set,
it is acceptible to add a new option to the union if the [appropriate conventions]
it is acceptable to add a new option to the union if the [appropriate conventions]
were followed in the original object. Removing an option requires following
the deprecation process.

View File

@@ -36,7 +36,7 @@ Documentation for other releases can be found at
## Overview
End-to-end (e2e) tests for Kubernetes provide a mechanism to test end-to-end behavior of the system, and is the last signal to ensure end user operations match developer specifications. Although unit and integration tests should ideally provide a good signal, the reality is in a distributed system like Kubernetes it is not uncommon that a minor change may pass all unit and integration tests, but cause unforseen changes at the system level. e2e testing is very costly, both in time to run tests and difficulty debugging, though: it takes a long time to build, deploy, and exercise a cluster. Thus, the primary objectives of the e2e tests are to ensure a consistent and reliable behavior of the kubernetes code base, and to catch hard-to-test bugs before users do, when unit and integration tests are insufficient.
End-to-end (e2e) tests for Kubernetes provide a mechanism to test end-to-end behavior of the system, and is the last signal to ensure end user operations match developer specifications. Although unit and integration tests should ideally provide a good signal, the reality is in a distributed system like Kubernetes it is not uncommon that a minor change may pass all unit and integration tests, but cause unforeseen changes at the system level. e2e testing is very costly, both in time to run tests and difficulty debugging, though: it takes a long time to build, deploy, and exercise a cluster. Thus, the primary objectives of the e2e tests are to ensure a consistent and reliable behavior of the kubernetes code base, and to catch hard-to-test bugs before users do, when unit and integration tests are insufficient.
The e2e tests in kubernetes are built atop of [Ginkgo](http://onsi.github.io/ginkgo/) and [Gomega](http://onsi.github.io/gomega/). There are a host of features that this BDD testing framework provides, and it is recommended that the developer read the documentation prior to diving into the tests.

View File

@@ -89,7 +89,7 @@ to update docker image address if youre not using GCR and default image name*
- Waits until all HollowNodes are in the Running phase (*will work exactly the same everywhere*)
<sub>\* Port 443 is a secured port on the master machine which is used for all external communication with the API server. In the last sentence *external* means all traffic
comming from other machines, including all the Nodes, not only from outside of the cluster. Currently local components, i.e. ControllerManager and Scheduler talk with API server using insecure port 8080.</sub>
coming from other machines, including all the Nodes, not only from outside of the cluster. Currently local components, i.e. ControllerManager and Scheduler talk with API server using insecure port 8080.</sub>
### Running e2e tests on Kubemark cluster

View File

@@ -104,7 +104,7 @@ The high level steps to update docs in an existing collection are:
## Updating docs on HEAD
[Development guide](development.md) provides general instructions on how to contribute to kubernetes github repo.
[Docs how to guide](how-to-doc.md) provides conventions to follow while writting docs.
[Docs how to guide](how-to-doc.md) provides conventions to follow while writing docs.
## Updating docs in release branch