mirror of
https://github.com/k3s-io/kubernetes.git
synced 2025-09-13 21:25:09 +00:00
Spelling fixes inspired by github.com/client9/misspell
This commit is contained in:
@@ -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
|
||||
|
||||
|
@@ -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.
|
||||
|
||||
|
@@ -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.
|
||||
|
||||
|
@@ -89,7 +89,7 @@ to update docker image address if you’re 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
|
||||
|
||||
|
@@ -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
|
||||
|
||||
|
Reference in New Issue
Block a user