This commit adds support to core resources to enable deferred deletion
of resources. Clients may optionally specify a time period after which
resources must be deleted via an object sent with their DELETE. That
object may define an optional grace period in seconds, or allow the
default "preferred" value for a resource to be used. Once the object
is marked as pending deletion, the deletionTimestamp field will be set
and an etcd TTL will be in place.
Clients should assume resources that have deletionTimestamp set will
be deleted at some point in the future. Other changes will come later
to enable graceful deletion on a per resource basis.
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.
* Make Codec separate from Scheme
* Move EncodeOrDie off Scheme to take a Codec
* Make Copy work without a Codec
* Create a "latest" package that imports all versions and
sets global defaults for "most recent encoding"
* v1beta1 is the current "latest", v1beta2 exists
* Kill DefaultCodec, replace it with "latest.Codec"
* This updates the client and etcd to store the latest known version
* EmbeddedObject is per schema and per package now
* Move runtime.DefaultScheme to api.Scheme
* Split out WatchEvent since it's not an API object today, treat it
like a special object in api
* Kill DefaultResourceVersioner, instead place it on "latest" (as the
package that understands all packages)
* Move objDiff to runtime.ObjectDiff
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.
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.
* Add labels selector (same as List)
* Add fields selector
* Plan to let you select pods by Host and/or Status
* Add resourceVersion to let you resume a watch where you left off.
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.
Contains breaking API change on api.Status#Details (type change)
Turn Details from string -> StatusDetails - a general
bucket for keyed error behavior. Define an open enumeration
ReasonType exposed as Reason on the status object to provide
machine readable subcategorization beyond HTTP Status Code. Define
a human readable field Message which is common convention (previously
this was joined into Details).
Precedence order: HTTP Status Code, Reason, Details. apiserver would
impose restraints on the ReasonTypes defined by the main apiobject,
and ensure their use is consistent.
There are four long term scenarios this change supports:
1. Allow a client access to a machine readable field that can be
easily switched on for improving or translating the generic
server Message.
2. Return a 404 when a composite operation on multiple resources
fails with enough data so that a client can distinguish which
item does not exist. E.g. resource Parent and resource Child,
POST /parents/1/children to create a new Child, but /parents/1
is deleted. POST returns 404, ReasonTypeNotFound, and
Details.ID = "1", Details.Kind = "parent"
3. Allow a client to receive validation data that is keyed by
attribute for building user facing UIs around field submission.
Validation is usually expressed as map[string][]string, but
that type is less appropriate for many other uses.
4. Allow specific API errors to return more granular failure status
for specific operations. An example might be a minion proxy,
where the operation that failed may be both proxying OR the
minion itself. In this case a reason may be defined "proxy_failed"
corresponding to 502, where the Details field may be extended
to contain a nested error object.
At this time only ID and Kind are exposed
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.
Clayton Coleman