Add DataSource and TypedLocalObjectReference

[xing-yang]

What this PR does / why we need it:
This PR adds TypedLocalObjectReference in the core API and adds DataSource in PersistentVolumeClaimSpec.

It also enables feature gate for VolumeSnapshotDataSource.

This is part of the CSI snapshot design proposal to support restoring a volume from a snapshot:
kubernetes/community#2495

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
kubernetes/enhancements#177

Special notes for your reviewer:

Release note:

Added support to restore a volume from a volume snapshot data source. 

[xing-yang]

@jingxu97

[xing-yang]

@saad-ali

[neolit123]

/ok-to-test
/sig api-machinery
/sig storage

[fedebongio]

/assign @lavalamp

[saad-ali]

/lgtm
Looks good from sig-storage side.
Needs API Approval. CC @kubernetes/api-approvers
/assign @thockin

[thockin]

This PR is missing the readiness gate portion. Do you really want to merge this without that?

The risk is that you don't get the readiness done in time, and the release cuts with a half-cooked feature. We're trying to do less in-progress development in master to avoid this problem.

Should this wait for the readiness feature to be mergeable? Either as part of this PR or as a pre-req for this.

[thockin]

@lavalamp @kubernetes/sig-api-machinery-api-reviews I need a consult.

Is "kind" sufficient here? In general a kind holds something like "Endpoints" while apiVersion holds "extensions/v1beta1". In a context like this, I don't care which API version, but I do care which group.

[liggitt]

kind, API group, and name are the three bits of info needed to unambiguously reference a particular object (assuming you don't care what API version the thing chasing the reference chooses to use).

for example:

kubernetes/staging/src/k8s.io/api/rbac/v1/types.go

Lines 90 to 98 in 7749eea

	// RoleRef contains information that points to the role being used
	type RoleRef struct {
	// APIGroup is the group for the resource being referenced
	APIGroup string `json:"apiGroup" protobuf:"bytes,1,opt,name=apiGroup"`
	// Kind is the type of resource being referenced
	Kind string `json:"kind" protobuf:"bytes,2,opt,name=kind"`
	// Name is the name of resource being referenced
	Name string `json:"name" protobuf:"bytes,3,opt,name=name"`
	}

[thockin]

Thanks, Jordan, that's what I assumed. I saw that ObjectReference has a field "APIVersion" which seemed wrong... I didn't know this struct, but it makes more sense.

[xing-yang]

Added APIGroup.

[jingxu97]

Then we will add the APIGroup in the struct. I assumed it is required and user has to specify the APIGroup here for the data source.

[xing-yang]

@thockin We have another PR on the readiness gate depending on this PR: #67625. Do you want us to combine them into one PR? Thanks.

[xing-yang]

The pull-kubernetes-kubemark-e2e-gce-big test failure was not related to this PR. I'll re-run it.
Looks like another feature gate change just got merged, so I'll need to resolve the conflict and re-submit.

[xing-yang]

@thockin Jing and I discussed about this and want to make the following changes to the DataSource comments. Let us know what you think. Thanks!

// This field requires the VolumeSnapshotDataSource alpha feature gate to be enabled and
// currently VolumeSnapshot is the only supported data source. If the provisioner can support
// VolumeSnapshot data source, it will create a new volume and data will be restored to the volume
// at the same time. If the provisioner does not support VolumeSnapshot data source, the volume
// will not be created. In the future, we plan to support more data source types and the behavior of
// the provisioner may change.

[jingxu97]

@thockin The comment we have now only describes the provisioner behavior for the only supported data source type, VolumeSnapshot. For this case, the provisioner will create volume and put data in volume at the same time. For the data sources that will be added in the future, it might require an external data populator to handle the data copy. In this case, things will get more complicated. For example, although provisioner does not fully support the data source (it cannot copy data directly), it still creates the volume and let the data populator to handle the data copying. In case of data copy failure, an empty volume might be left there but PVC should be marked as not ready. We need more discussion to finalize the design and cover all the cases. When that feature is ready, we will come back and change the comments here. Please let us know if there is any problem with it. Thank you!

[xing-yang]

/test pull-kubernetes-e2e-gce

[xing-yang]

/test pull-kubernetes-kubemark-e2e-gce-big

[thockin]

/lgtm
/approve

[saad-ali]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: saad-ali, thockin, xing-yang

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• api/OWNERS [thockin]
• docs/api-reference/OWNERS [thockin]
• pkg/apis/core/OWNERS [thockin]
• pkg/features/OWNERS [saad-ali,thockin]
• staging/src/k8s.io/api/OWNERS [thockin]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[saad-ali]

/milestone v1.12

[k8s-github-robot]

/test all [submit-queue is verifying that this PR is safe to merge]

[k8s-github-robot]

Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions here: https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md.