summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMike Danese <mikedanese@gmail.com>2016-01-14 11:51:48 -0800
committerMike Danese <mikedanese@gmail.com>2016-01-14 11:51:48 -0800
commit7ae5438b8673e044684f26dc24c14d166befbf20 (patch)
tree145a581c12b7e60f3a5bb939aaf7d20ae92ca75d
parent91d952369f806ac5ffa741cfaa29a84947c6858e (diff)
parent11f05fc202c256e0ad84797bddcf68ea9af8e96e (diff)
Merge pull request #19278 from philips/minor-edits-to-apiserver-watch-scaling
docs: apiserver-watch: minor cleanups
-rw-r--r--apiserver-watch.md12
1 files changed, 6 insertions, 6 deletions
diff --git a/apiserver-watch.md b/apiserver-watch.md
index e112baff..b6962a5c 100644
--- a/apiserver-watch.md
+++ b/apiserver-watch.md
@@ -34,9 +34,9 @@ Documentation for other releases can be found at
## Abstract
-In the current system, all watch requests send to apiserver are in general
-redirected to etcd. This means that for every watch request to apiserver,
-apiserver opens a watch on etcd.
+In the current system, most watch requests sent to apiserver are redirected to
+etcd. This means that for every watch request the apiserver opens a watch on
+etcd.
The purpose of the proposal is to improve the overall performance of the system
by solving the following problems:
@@ -99,7 +99,7 @@ to implement the proposal.
1. Since we want the watch in apiserver to be optional for different resource
types, this needs to be self-contained and hidden behind a well defined API.
This should be a layer very close to etcd - in particular all registries:
-"pkg/registry/generic/etcd" should be build on top of it.
+"pkg/registry/generic/etcd" should be built on top of it.
We will solve it by turning tools.EtcdHelper by extracting its interface
and treating this interface as this API - the whole watch mechanisms in
apiserver will be hidden behind that interface.
@@ -169,8 +169,8 @@ the same time, we can introduce an additional etcd event type:
in places like
[Reflector](../../pkg/client/cache/reflector.go)
- However, this might turn out to be unnecessary optimization if apiserver
- will always keep up (which is possible in the new design). We will work
+ However, this might turn out to be unnecessary optimization if apiserver
+ will always keep up (which is possible in the new design). We will work
out all necessary details at that point.