df8551acd2
Automatic merge from submit-queue (batch tested with PRs 45272, 45115) initial types for TPRs This pull starts creating the types described by https://github.com/kubernetes/community/blob/master/contributors/design-proposals/thirdpartyresources.md . In the initial pull different names were suggested. I've started this pull with `CustomResource.apiextensions.k8s.io`. The structure begins as a separate API server to facilitate rapid prototyping and experimentation, but the end result will be added to the end of the `kube-apiserver` chain as described in https://github.com/kubernetes/community/blob/master/sig-api-machinery/api-extensions-position-statement.md . Because it is separate to start (not included in any default server), I don't think we need a perfect name, but I'd like to be close. @kubernetes/sig-api-machinery-misc @enisoc @smarterclayton @erictune |
||
|---|---|---|
| .. | ||
| src/k8s.io | ||
| README.md | ||
| copy.sh | ||
| godeps-json-updater.go | ||
| prime-apimachinery.sh | ||
README.md
This staging/src/k8s.io/client-go directory is the staging area of the client repo. It contains a versioned client, tools built around the client like the reflector, and all the client dependencies. The content will be periodically published to k8s.io/client-go repo.
The staged content is copied from the main repo, i.e., k8s.io/kubernetes, with directory rearrangement and necessary rewritings. To sync the content with the latest code in your local k8s.io/kubernetes, you need to run godep restore in k8s root directory, then run staging/copy.sh.
vendor/k8s.io/client-go is a symlink pointing to this staging area, so to use the packages in the staging area, you can import it as "vendor/client-go/", as if the client were vendored. The client will be vendored from k8s.io/client-go for real after the test matrix is converted to vendor k8s components.