Change:
What happened: If an in-tree volume is provisioned with in-tree provisioner (without migration enabled) and later migration gets enabled, the PV controller is expected to coordinate with the CSI external provisioner to make sure it does get deleted. For above to happen, this in the PV controller needs to return nil, nil even if is set to a plugin prefixed with . The CSI external provisioner also needs to be enhanced to delete PV's whose is set to a plugin prefixed with . We also need to prevent a race between external provisioner and in-tree PV controller in the delete path when CSI Migration flag is disabled. To achieve this synchronization, PV controller will need to mark the in-tree PVs that need to be deleted by external provisioner with an additional annotation to signal that CSI Migration flag is enabled in-tree and the CSI external provisioner needs to process the deletion. What you expected to happen: CSI driver should process the deletion. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.15 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:
/assign
/sig storage
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
Instead of this would it be possible to just change the annotation on the . That is the signal. Otherwise we run the risk of adding yet another condition to the already complex logic. I wonder if its possible to have the PV controller go in and switch them all on when it detects is on.
cc
This is a high priority to be fixed and should be cherry-picked as well if possible
I'd like to raise the priority for this one as well, especially after the explicit end-user ask for migration to CSI (for AWS EBS and GCE PD, at least) in the official 1.17.0 release notes. IMO it's not possible to migrate because deletion of PVs created before CSI migration does not work due to this bug. See also:
/open no current released versions of Kubernetes or External-provisioner where this is fixed. Likely to be and
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

Discussion:
set -o pipefail IFS=$'nt' <del> SCRIPT_DIR=$(cd $(dirname $0); pwd) </del> <ins> SCRIPT_DIR=$(CDPATH="" cd $(dirname $0); pwd) </ins> INSTANCE_PREFIX=$1

# exit on any error set -e <del> SCRIPT_DIR=$(cd $(dirname $0); pwd) </del> <ins> SCRIPT_DIR=$(CDPATH="" cd $(dirname $0); pwd) </ins> source $SCRIPT_DIR/config.sh