summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorBrandon Philips <brandon.philips@coreos.com>2015-12-26 10:19:03 -0800
committerBrandon Philips <brandon.philips@coreos.com>2015-12-26 10:19:03 -0800
commit11f05fc202c256e0ad84797bddcf68ea9af8e96e (patch)
treef6db2efffc2973bb969795b1537ec1195ea05c15
parent75500fd9f484b9e451b445793af3c3cb3caf0f99 (diff)
docs: apiserver-watch: minor cleanups
Reading through this doc I found a few grammar things to fix.
-rw-r--r--apiserver-watch.md12
1 files changed, 6 insertions, 6 deletions
diff --git a/apiserver-watch.md b/apiserver-watch.md
index f2011f13..8e0d2a44 100644
--- a/apiserver-watch.md
+++ b/apiserver-watch.md
@@ -33,9 +33,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:
@@ -98,7 +98,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.
@@ -168,8 +168,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.