Allows better semantic use of Request when dealing with sub resources,
and allows clients to ignore ordering. Supports multiple segments because
sub-resources are less tightly structured than regular resources.
Revise our code to only call Request.Namespace() if a namespace
*should* be present. For root scoped resources, namespace should
be ignored. For namespaced resources, it is an error to have
Namespace=="".
RESTClient is an abstraction on top of arbitrary HTTP endpoints that
follow the Kubernetes API conventions. Refactored RESTClientFor so that
assumptions that are Kube specific happen outside of that method (so
others can reuse the RESTClient). Added more validation to client.New
to ensure clients give good input. Exposed APIVersion on RESTClient
as a method so that wrapper code (code that adds typed / structured
methods over rest endpoints like client.Client) can more easily make
decisions about what APIVersion it is running under.
RESTClient is an abstraction for simplifying access to resources that
follow the Kubernetes API pattern. Currently, both Namespace and Path
are coupled, which means changes across versions is complex. In general,
most access to resources should be to a resource collection (e.g.
"services") with a name (e.g. "foo"). Other constructs, like prefix sections
("watch") or proposed suffix sections ("/pods/foo/spec") only modify this
core pattern.
This commit removes the Path() helper from Request and introduces:
* Prefix(segments ...string) - segments that should go to the beginning of the path.
* Suffix(segments ...string) - segments that should go to the end of the path.
* Resource(string) - collection name, should be after prefix
* Namespace(string) - if specified, should be set after resource but before name
* Name(string) - if specified, should be after namespace
Now, only Prefix and Suffix are order dependent (and with variadics, should be
simpler). Resource, Namespace, and Name may be specified in any order.
Path() has been removed to prevent downstream consumers of RESTClient from experiencing
behavior change.
Watch depends on long running connections, which intervening proxies
may break without the control of the remote server. Specific errors
handled are io.EOF, io.EOF wrapped by *url.Error, http connection
reset errors (caused by race conditions in golang http code), and
connection reset by peer (simply tolerated).
Add a Visitor pattern on top of ResourcesFromArgs
Allows ResourcesFromArgs to return an opaque list of items and have client
commands react to them.
Change request.go to return apiserver errors for arbitrary status codes to
better respond to generic actions that don't make sense (kubectl delete operations foo)
PUT allows an object to be created (http 201). This allows REST code to
indicate an object has been created and clients to react to it.
APIServer now deals with <-chan RESTResult instead of <-chan runtime.Object,
allowing more data to be passed through.
Allows us to define different watch versioning regimes in the future
as well as to encode information with the resource version.
This changes /watch/resources?resourceVersion=3 to start the watch at
4 instead of 3, which means clients can read a resource version and
then send it back to the server. Clients should no longer do math on
resource versions.
Clayton Coleman