- Separating out index, version and api handlers into independent web
services. Moved the index handler to /welcome, version handler to
/version and the api handler to /api,
Moved code from cmd/apiserver to pkg/master.
test/integration/client_test made to use a master object,
instead of an apiserver.Handle.
Subsequent PRs will move more handler-installation into
pkg/master, with the goal that every http.Handler of a
standalone apiserver process can also be tested
in a "testing"-style go test.
In particular, a subsequent PR will test
authorization.
To proxy traffic to anything that implements ResourceLocation.
Currently, this is only services. This is easily extensible to minions
(would supercede existing mechanism) and pods.
Also rename some to other names that make better reading. There are still a
bunch of "make" functions but they do things like assemble a string from parts
or build an array of things. It seemed that "make" there seemed fine. "New"
is for "constructors".
Prepare for running multiple API versions on the same HTTP server
by decoupling some of the mechanics of apiserver. Define a new
APIGroup object which represents a version of the API.
Unify error handling in apiserver into a single path - RESTStorage
objects must provide appropriate errors individually. Ensure ALL
errors which can be traced to logical faults with RESTStorage are
returned as api.Status objects.
The apiserver on initialization must be provided with a codec
for encoding and decoding all handled objects including api.Status
and api.ServerOp. In addition, the RESTStorage Extract() method
has been changed to New(), which returns a pointer object that the
codec must decode into (the internal object). Switched registry
methods to use pointers for Create/Update instead of values.
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.
