Files
kubernetes/staging
Kubernetes Submit Queue d56f6ef816 Merge pull request #49971 from deads2k/discovery-01-group
Automatic merge from submit-queue (batch tested with PRs 49971, 51357, 51616, 51649, 51372)

add information for subresource kind determination

xref https://github.com/kubernetes/kubernetes/issues/38810 https://github.com/kubernetes/kubernetes/issues/38756

Polymorphic subresources usually have different groupVersions for their discovery kinds than their "native" groupVersions.  Even though the APIResourceList shows the kind properly, it does not reflect the group or version of that kind, which makes it impossible to unambiguously determine if the subresource matches you and it is impossible to determine how to serialize your data.  See HPA controller.

This adds an optional Group and Version to the discovery doc, which can be used to communicate the "native" groupversion of an endpoint.  Doing this does not preclude fancier contenttype negotiation in the future and doesn't prevent future expansion from indicating equivalent types, but it does make it possible to solve the problem we have today or polymorphic categorization.

@kubernetes/sig-api-machinery-misc @smarterclayton 
@cheftako since @lavalamp is out.

```release-note
Adds optional group and version information to the discovery interface, so that if an endpoint uses non-default values, the proper value of "kind" can be determined. Scale is a common example.
```
2017-09-01 01:12:36 -07:00
..
2017-04-19 15:58:09 -04:00

External Repository Staging Area

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.

Repositories currently staged here:

The code in the staging/ directory is authoritative, i.e. the only copy of the code. You can directly modify such code.

Using staged repositories from Kubernetes code

Kubernetes code uses the repositories in this directory via symlinks in the vendor/k8s.io directory into this staging area. For example, when Kubernetes code imports a package from the k8s.io/client-go repository, that import is resolved to staging/src/k8s.io/client-go relative to the project root:

// pkg/example/some_code.go
package example

import (
  "k8s.io/client-go/dynamic" // resolves to staging/src/k8s.io/client-go/dynamic
)

Once the change-over to external repositories is complete, these repositories will actually be vendored from k8s.io/<package-name>.