Currently, every write will result in a 202 (etcd adding a few
ms of latency to each request). This forces clients to go into
a poll loop and pick a reasonable server poll frequency, which
results in 1 + N queries to the server for the single operation
and adds unavoidable latency to each request which affects their
perception of the service.
Add a very slight (25ms by default) delay to wait for requests
to finish. For clients doing normal writes this reduces the
requests made against the server to 1. For clients on long requests
this has no effect. The downside is that http connections are held
on to for a longer period in high write loads. The decrease in
perceived latency from the kubecfg is significant.
Implemented via HTTP and websocket. A test is present but this isn't
yet wired into anything.
Eventual purpose of this is to allow a scheduler to watch for new pods.
Or allow replication controller to watch for new items it controlls.
Generally, it'll be good to turn everything possible into a push instead
of a poll.
