New(?) restrictions regarding secret naming (error message "could not get account name from <actual-secret-name>, correct format: azure-storage-account-(.+)-secret" in kube-controller-manager logs)

[jgoeres]

Hi,

we recently switched to AKS versions which deprecated resp. removed the old in-tree AzureFile provisioner and are now using the azurefile-csi-driver. We now noticed that the kube-controller-manager logs are filled with messages of this form

could not get account name from <actual-secret-name>, correct format: azure-storage-account-(.+)-secret

where is the name of the secret that we generate for referencing in the PV. Interestingly, the shares seem to work just fine and we are now wondering if we really need to fix this resp. what are the implications if we ignore this. While changing the secret name is not that big a deal for newly set up clusters, changing it for existing ones (and we do have quite a few) would be a challenge - PVs are largely immutable, if one tries to change the name of the secret, this is what you get:

The PersistentVolume "foobar" is invalid: spec.persistentvolumesource: Forbidden: spec.persistentvolumesource is im
mutable after creation
  core.PersistentVolumeSource{
        ... // 11 identical fields
        FC:      nil,
        Flocker: nil,
        AzureFile: &core.AzureFilePersistentVolumeSource{
-               SecretName:      "azure-storage-account-hei07opei-secret",
+               SecretName:      "our-old-secret-name-here",

Aside from some clarification regarding the urgency of fixing this for existing clusters, I wonder why this requirement regarding the secret name came into being - after all, the storage account name can be found in the secret itself. So maybe someone can shed some light on the need for this naming convention.

THX J

[andyzhangx]

this error message is actually a warning message in TranslateInTreePVToCSI: could not get account name from <actual-secret-name>, correct format: azure-storage-account-(.+)-secret which is used to get volumeID with an account name. if you have set secret name correctly, the azure file driver could get account name from secret directly.

And you are using in-tree AzureFile PV, I would suggest using Azure File CSI driver PV directly.