I ran into an issue where the current code is forcing the creation of PV with specific volume names. This is causing some issues when trying to use a custom StorageClass like:
I also discovered that the current sharedDisk implementation appear to be broken... There is only a private shareddisk pv yaml file. When trying to use the default shareddisk values the deployment will keep failing. Disabling the volumeName and ensuring the shareddisk-private.yaml is not used fixed the issue for me.
This is allowing me to move the public and private PV to faster azurefile-csi-premium driver and not have to create fileshare in a storage account. The azurefile-csi-premium offer significant performance gain over the previous azurefile on a storage account method.
I still use an azurefile backup PV to store backups.
I ran into an issue where the current code is forcing the creation of PV with specific volume names. This is causing some issues when trying to use a custom StorageClass like:
I created a new pull request to allow the disabling of volumeNames for the shareddisk and azurefile PVC:
https://github.com/drupalwxt/helm-drupal/pull/116
I also discovered that the current sharedDisk implementation appear to be broken... There is only a private shareddisk pv yaml file. When trying to use the default shareddisk values the deployment will keep failing. Disabling the volumeName and ensuring the shareddisk-private.yaml is not used fixed the issue for me.
This is allowing me to move the public and private PV to faster azurefile-csi-premium driver and not have to create fileshare in a storage account. The azurefile-csi-premium offer significant performance gain over the previous azurefile on a storage account method.
I still use an azurefile backup PV to store backups.