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

Merge pull request #1405 from porridge/minor-wording 

Automatic merge from submit-queue.

Some minor wording fixes.

/cc @shyamjvs
This commit is contained in:
Kubernetes Submit Queue 2017-11-15 05:21:12 -08:00 committed by GitHub
parent 060c2c72f7 bcaad8a2f3
commit 38b96107ff
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
contributors/devel/release/scalability-validation.md
View File

@ -15,7 +15,7 @@ In this document, we address the following process-related problems wrt scale te
## Non-Goals
We do not intend to:
This document does not intend to:
- Define the set of tests that comprise scalability and correctness suite
- Define SLIs/SLOs (that’s discussed [here]) and thresholds for the tests
@ -40,7 +40,7 @@ We need to run them on 5k-node clusters, but they’re:
- Expensive (tens of thousands of core hours per run)
- Blocking other large tests (quota limitations + only one large test project available viz. 'kubernetes-scale')
So we don’t want to run them too frequently. On the other hand, running them too infrequently means late identification and piling up of regressions. So we choose the following middleground:
So we don’t want to run them too frequently. On the other hand, running them too infrequently means late identification and piling up of regressions. So we choose the following middleground:
(B = release-blocking, NB = not release-blocking)
- Performance tests on 2k-node cluster in GCE/GKE alternatingly each week (NB)
@ -77,7 +77,7 @@ Google is currently using a single project for scalability testing, on both GCE
### Concretely define test configuration
This is a relatively minor issue but it is important that we clearly define the test configuration we use for the release. E.g. there was a confusion this time around testing k8s services, machine-type and no. of the nodes we used (we tested 4k instead of 5k due to a CIDR-setup problem). For ref - [#47344] [#47865]. To solve this, we need to document it using the below template in a file named scalability-validation-report.md placed under kubernetes/features/release-<N>. And this file should be linked from under the scalability section in the release's CHANGELOG.md.
This is a relatively minor issue but it is important that we clearly define the test configuration we use for the release. E.g. there was a confusion this time around testing k8s services, machine-type and no. of the nodes we used (we tested 4k instead of 5k due to a CIDR-setup problem). For ref - [#47344] [#47865]. To solve this, we need to document it using the below template in a file named scalability-validation-report.md placed under kubernetes/features/release-&gt;N&lt;. And this file should be linked from under the scalability section in the release's CHANGELOG.md.
```
Validated large cluster performance under the following configuration: