07f85565a2
Automatic merge from submit-queue Add initializer support to admission and uninitialized filtering to rest storage Initializers are the opposite of finalizers - they allow API clients to react to object creation and populate fields prior to other clients seeing them. High level description: 1. Add `metadata.initializers` field to all objects 2. By default, filter objects with > 0 initializers from LIST and WATCH to preserve legacy client behavior (known as partially-initialized objects) 3. Add an admission controller that populates .initializer values per type, and denies mutation of initializers except by certain privilege levels (you must have the `initialize` verb on a resource) 4. Allow partially-initialized objects to be viewed via LIST and WATCH for initializer types 5. When creating objects, the object is "held" by the server until the initializers list is empty 6. Allow some creators to bypass initialization (set initializers to `[]`), or to have the result returned immediately when the object is created. The code here should be backwards compatible for all clients because they do not see partially initialized objects unless they GET the resource directly. The watch cache makes checking for partially initialized objects cheap. Some reflectors may need to change to ask for partially-initialized objects. ```release-note Kubernetes resources, when the `Initializers` admission controller is enabled, can be initialized (defaulting or other additive functions) by other agents in the system prior to those resources being visible to other clients. An initialized resource is not visible to clients unless they request (for get, list, or watch) to see uninitialized resources with the `?includeUninitialized=true` query parameter. Once the initializers have completed the resource is then visible. Clients must have the the ability to perform the `initialize` action on a resource in order to modify it prior to initialization being completed. ```
This directory is the staging area for packages that have been split to their own repository. The content here will be periodically published to respective top-level k8s.io repositories.
Most code in the staging/ directory is authoritative, i.e. the only copy of
the code. You can directly modify such code. However the packages in
staging/src/k8s.io/client-go/pkg are copied from pkg/. If you modify the
original code in pkg/, you need to run hack/godep-restore.sh from the k8s
root directory, followed by hack/update-staging-client-go.sh. We are working
towards making all code in staging/ authoritative.
The vendor/k8s.io directory contains symlinks pointing to this staging area,
so to use a package in the staging area, you can import it as
k8s.io/<package-name>, as if the package were vendored. Packages will be
vendored from k8s.io/<package-name> for real after the test matrix is
converted to vendor k8s components.