Change:
// called from provisionClaim(), in this case, plugin MUST NOT be nil // NOTE: checks on plugin/storageClass has been saved pluginName := plugin.GetPluginName() <ins> if pluginName != "kubernetes.io/csi" && claim.Spec.DataSource != nil { // Only CSI plugin can have a DataSource. Fail the operation // if Datasource in Claim is not nil and it is not a CSI plugin, strerr := fmt.Sprintf("plugin %q is not a CSI plugin. Only CSI plugin can provision a claim with a datasource", pluginName) klog.V(2).Infof(strerr) ctrl.eventRecorder.Event(claim, v1.EventTypeWarning, events.ProvisioningFailed, strerr) return pluginName, fmt.Errorf(strerr) } </ins> provisionerName := storageClass.Provisioner <ins> klog.V(4).Infof("provisionClaimOperation [%s]: plugin name: %s, provisioner name: %s", claimToClaimKey(claim), pluginName, provisionerName) </ins> // Add provisioner annotation to be consistent with external provisioner workflow newClaim, err := ctrl.setClaimProvisioner(claim, provisionerName)

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: In clusters that have intree drivers as the default storageclass, if you try to create a PVC with snapshot data source and forget to put the csi storageclass in it, then an empty PVC will be provisioned using the default storageclass. What you expected to happen: PVC creation should not proceed and instead have an event with an incompatible error, similar to how we check proper csi driver in the csi provisioner. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
I think similar issue exists with cloning. We'll need to think about what the behavior should be for data populators too. cc
/triage accepted
Scenario to reproduce the issue Create the nginx deployment and the PVC used by it Exec into the running container, cd into the PVC mounted path and create some files Create the following using as source the The used is the following and wait until it becomes Delete the deployment and the initial PVC Create a new PVC, using the previously created as its Set the name of the new (restored) PVC to the nginx deployment and create the again into the PVC mounted directory. It should contain the previously created files but its empty
can you modify the title of this issue and change to ? In addition to snapshot datasource, using PVC datasource and AnyVolumeDataSource should also fail for in-tree PVC.
/assign
I wasn't 100% sure on data populators. Because it shouldn't have a dependency on CSI right?
I guess even if data populators does support intree volumes, pv controller should ignore it similar to csi provisioner
It may or may not have a dependency on CSI. Design is still in progress. We can leave it out for now until we know exactly how to use it. One thing I know is that the any volume data source cannot be an in-tree k8s resource.
Yes, we can actually just ignore it in pv controller.

Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
I'm getting same with longhorn, is this issue resolved on your side?