You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am trying to use the CSI Volume Cloning feature to copy a blob volume from a source storage account with Blob Data Reader into a destination storage account with Blob Data Contributor.
This is desirable in order to dynamically provision a copy of a blob container from a read-only global source storage account into a read-write cluster adjacent regional destination storage account, which can then be automatically reclaimed when no longer needed.
It appears that when cloning a blob volume, the controller server mistakenly attempts to provision the new blob container in the source storage account instead of the destination storage account.
The system identity does not have the permissions to write to the source storage and fails.
I am including a lightly anonymized copy of the logs and kubernetes resources for repro.
What happened:
controller.go:1366] provision "datacopy" class "datacopy": started
event.go:298] Event(External provisioner is provisioning volume for claim "datacopy"
utils.go:104] GRPC call: /csi.v1.Controller/CreateVolume
utils.go:105] GRPC request: {"capacity_range":{"required_bytes":274877906944},"name":"pvc-f0b58822-7342-4933-85b1-17ecf2ea94a6","parameters":{"csi.storage.k8s.io/pv/name":"pvc-f0b58822-7342-4933-85b1-17ecf2ea94a6","csi.storage.k8s.io/pvc/name":"data","protocol":"fuse2","resourceGroup":"resourceGroupDatacopy","storageAccount":"storageAccountDatacopy","storeAccountKey":"false"},"volume_capabilities":[{"AccessType":{"Mount":{"mount_flags":["--cancel-list-on-mount-seconds=0","-o allow_other","-o attr_timeout=120","-o entry_timeout=120","-o negative_timeout=120"]}},"access_mode":{"mode":3}}],"volume_content_source":{"Type":{"Volume":{"volume_id":"resourceGroupDatasource#storageAccountDatasource#containerNameDatasource"}}}}
controllerserver.go:802] use system-assigned managed identity to authorize azcopy
controllerserver.go:750] begin to copy blob container datasource to pvc-f0b58822-7342-4933-85b1-17ecf2ea94a6
controllerserver.go:760] copy blob container datasource to pvc-f0b58822-7342-4933-85b1-17ecf2ea94a6
controllerserver.go:767] CopyBlobContainer(resourceGroupDatasource, storageAccountDatasource, https://storageAccountDatasource.blob.core.windows.net/pvc-f0b58822-7342-4933-85b1-17ecf2ea94a6) failed with error(exit status 1):
INFO: Scanning...
INFO: Login with identity succeeded.
INFO: Authenticating to destination using Azure AD
INFO: Authenticating to source using Azure AD
INFO: Failed to create one or more destination container(s). Your transfers may still succeed if the container already exists.
INFO: Authentication failed, it is either not correct, or expired, or does not have the correct permission PUT https://storageAccountDatasource.blob.core.windows.net/pvc-f0b58822-7342-4933-85b1-17ecf2ea94a6/file4.bin
What you expected to happen:
A dynamic blob container should have been provisioned in the storage account specified in the datacopy storage class.
How to reproduce it:
See example kubernetes specs below.
Anything else we need to know?:
Functioning volume cloning is a highly desirable feature.
I believe the copyVolume method should receive dstResourceGroup, dstAccountName parameters from CreateVolume to be used inside copyBlobContainer which currently builds the dstPath using the source accountName which is incorrect.
I am trying to use the CSI Volume Cloning feature to copy a blob volume from a source storage account with
Blob Data Reader
into a destination storage account withBlob Data Contributor
.This is desirable in order to dynamically provision a copy of a blob container from a read-only global source storage account into a read-write cluster adjacent regional destination storage account, which can then be automatically reclaimed when no longer needed.
It appears that when cloning a blob volume, the controller server mistakenly attempts to provision the new blob container in the source storage account instead of the destination storage account.
The system identity does not have the permissions to write to the source storage and fails.
I am including a lightly anonymized copy of the logs and kubernetes resources for repro.
What happened:
What you expected to happen:
A dynamic blob container should have been provisioned in the storage account specified in the datacopy storage class.
How to reproduce it:
See example kubernetes specs below.
Anything else we need to know?:
Functioning volume cloning is a highly desirable feature.
Environment:
mcr.microsoft.com/oss/kubernetes-csi/blob-csi:v1.23.4
kubectl version
):Client Version: v1.29.2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.28.10
The text was updated successfully, but these errors were encountered: