-
Notifications
You must be signed in to change notification settings - Fork 39.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cleaned enable pvc datasource #76913
Cleaned enable pvc datasource #76913
Conversation
This supersedes #76913 |
This PR may require API review. If so, when the changes are ready, complete the pre-review checklist and request an API review. Status of requested reviews is tracked in the API Review project. |
Unknown CLA label state. Rechecking for CLA labels. Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
pkg/features/kube_features.go
Outdated
@@ -504,6 +510,7 @@ var defaultKubernetesFeatureGates = map[utilfeature.Feature]utilfeature.FeatureS | |||
NodeLease: {Default: true, PreRelease: utilfeature.Beta}, | |||
SCTPSupport: {Default: false, PreRelease: utilfeature.Alpha}, | |||
VolumeSnapshotDataSource: {Default: false, PreRelease: utilfeature.Alpha}, | |||
VolumePVCDataSource: {Default: false, PreRelease: utilfeature.Alpha}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On a second thought, I think "PVCDataSource" is better. We can't drop "Volume" from "VolumeSnapshotDataSource" because a snapshot could be for something else such as a database.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that naming gets ugly 👍
2199b6f
to
8f2b9a9
Compare
My comment is addressed. LGTM |
LGTM from my side. There is a small change in types.go, an already existing field is extended and its documentation is updated. Let's start formal review, it can be always shortened. /label api-review |
/assign @saad-ali |
lgtm from my side . Thanks @j-griffith ! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What bad things happen if we let users put whatever they want in this field and have the provisioners be responsible for checking the flag gate and eventing "not supported" ?
@@ -52,3 +52,20 @@ func volumeSnapshotDataSourceInUse(oldPVCSpec *core.PersistentVolumeClaimSpec) b | |||
} | |||
return false | |||
} | |||
|
|||
func dataSourceIsEnabled(pvcSpec *core.PersistentVolumeClaimSpec) bool { | |||
if pvcSpec.DataSource != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really need this level of checking? I mean, is it possible that external controllers could consume this with other types that we don't know about here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO no, in fact I thought it seemed redundant and had initially just removed the restrictions on the datasource field with a new feature gate and called it done. Yes, my thought was this was designed for external controllers and I'd love to be able to use it as such. During conversations I was asked to add the checks back in.
I'm probably not helping myself out here.
pkg/apis/core/types.go
Outdated
// If the provisioner does not support VolumeSnapshot data source, volume will | ||
// This field can be used to specify either: | ||
// * An existing VolumeSnapshot object (snapshot.storage.k8s.io/VolumeSnapshot) | ||
// * An existing PVC (""/PersistentVolumeClaim) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whats with teh quotes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, fixed.
@thockin Not much really, either it does "nothing" because there isn't another controller looking for it or acting upon it, or said entry is valid and it's acted upon (or rejected) by the interested controller. |
I'm fine with this for alpha, but it seems like the final state is that the provisioner is responsible for evaluating this and deciding whether it supports the source or not (and in fact, already not all provisioners will support all sources or even support any source at all, right)? I leave it to you and SIG (@saad-ali and @msau42 assigned here) to decide, but I will approve as-is. /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: j-griffith, saad-ali, thockin 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:
Approvers can indicate their approval by writing |
The idea was to start off strict and loosen over time: only allow specific datasources initially, and loosen over time to eventually allow arbitrary datasources. In order to support aribitrary datasources we want to formalize the idea of "populators" independent of "provisioners". We haven't gotten that far yet, so for now we're just slightly loosening, instead of allowing anything. |
@j-griffith: you cannot LGTM your own PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/lgtm |
This enables the ability to specify and existing PVC as a DataSource in a new PVC Spec (eg "clone" and existing volume).
Update the unit tests to include checks for incorrect APIGroup type in PVC DataSource and change the name of the feature gate to be more clear: s/VolumeDataSource/VolumePVCDataSource/
This enables the ability to specify and existing PVC as a DataSource in a new PVC Spec (eg "clone" and existing volume).
f57bcbb
to
62a4861
Compare
@saad-ali I had to rebase; shouldn't be anything else added if you could reapply lgtm |
/lgtm |
This enables the ability to specify and existing PVC as a DataSource in
a new PVC Spec (eg "clone" and existing volume).
What type of PR is this?
What this PR does / why we need it:
Currently the only valid input Kind for PVC DataSource is "VolumeSnapshot", this feature adds the ability to also specify a DataSource Kind of "PersistentVolumeClaim".
This results in the ability for a user to specify intent to clone and existing PVC, it does NOT implement cloning functionality in Kubernetes; that's left to the external csi provisioner and plugins. It does however provide a mechanism to request a clone operation to the csi-provisioner and ultimately the csi plugin that the original PVC is allocated from.
Currently (as of 1.14) a user is able to enter a DataSource with any information they wish, however if it's not of the type "VolumeSnapshot" and the "VolumeSnapshotDataSource" feature gate is not enabled, the input is nilled and silently ignored. This change follows the same pattern, via the "VolumeDataSource" feature gate.
Which issue(s) this PR fixes:
Implements enhancement/KEP 642
Issue kubernetes/enhancements#989
Special notes for your reviewer:
Does this PR introduce a user-facing change?: