Open gbxahollis opened 4 years ago
batiati
commented
4 years ago I'm facing the same issue, it's expected to be disconnect in order allow further operations by the SAN (destroy the volume for example)
FlexVolumes itself has been kind of deprecated ... is this project still supported?
KnicKnic
commented
4 years ago Currently the code leaves the target & lun connected incase it is being used by another container on the host. You could submit a PR to disconnect it in the unmount and make it optional in the storage class. https://github.com/microsoft/K8s-Storage-Plugins/blob/e683bce3c33df06417775378d7bb5b1d4cfe92d3/flexvolume/windows/plugins/microsoft.com~iscsi.cmd/iscsi.ps1#L608 is where the dismount code exists. But please be mindful of refcounting issues of multiple uses of the target
It has been a bit of time since I originally wrote this code, but if I remember correct due to the nature of flexvolume the information containing refcounts of how many workloads are using the drive where not plumbed if you needed passwords. See https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md#unmount-device
The FlexProvisioner written against the Microsoft iSCSI target server does a forceful disconnect of drives during the delete. See https://github.com/microsoft/K8s-Storage-Plugins/blob/e683bce3c33df06417775378d7bb5b1d4cfe92d3/flexprovisioner/src/iscsi.ps1#L132
As far as deprecated. FlexVolume is an hosted plugin in kubernetes codebase. Kubernetes is currently trying to move all the plugins outside of the tree. FlexVolume will exist for the time being to support existing users. Linux development for iSCSI CSI drivers for kubernetes is at https://github.com/kubernetes-csi/csi-driver-iscsi
I've noticed that when I delete a workload that had an iSCSI Flexvolume mounted, it leaves the target and LUN connected on the host. Should it be automatically disconnecting that target after a workload has been removed?