fix: check storage account type if parameter is missing

[RomanBednar]

What type of PR is this?
/kind bug

What this PR does / why we need it:

While using StorageClass with samba protocol without explicitly specifying strorage account type users get a misleading message and volume creation fails:

Status=400 Code="InvalidHeaderValue" Message="The value for one of the HTTP headers is not in the correct format.

This happens in a scenario when creating a volume with size < 100Gi and storage account name (premium type) was provided as a parameter in StorageClass while skuName was omitted. Premium requirement is that a fileshare must have at least 100Gi in size.

Driver can lookup storage account type via storage account client and use that instead of relying on theskuName parameter that users otherwise need to set manually.

Which issue(s) this PR fixes:

Fixes #1390

Requirements:

• uses conventional commit messages
• includes documentation
• adds unit tests
• tested upgrade from previous version

Special notes for your reviewer:

Release note:

`skuName` storage class parameter is now optional when using premium storage account with volume sizes below 100Gi

[andyzhangx]

also add fileShareSize < minimumPremiumShareSize check, that could save one StorageAccountClient.GetProperties call: sku is only needed when fileShareSize < minimumPremiumShareSize

[RomanBednar]

Added, along with one more unit test to verify StorageAccountClient.GetProperties is not called in this case.

[RomanBednar]

/hold

I get an error while obtaining storage account properties, need to investigate.

E0824 12:33:51.882227 1 utils.go:81] GRPC error: rpc error: code = Internal desc = failed to get properties on storage account account(rbednarplrs) rg(), error: &{false 400 0001-01-01 00:00:00 +0000 UTC {"error":{"code":"InvalidApiVersionParameter","message":"The api-version '2021-02-01' is invalid. The supported versions are '2023-07-01,2023-07-01-preview,2023-03-01-preview,2022-12-01,2022-11-01-preview,2022-09-01,2022-06-01,2022-05-01,2022-03-01-preview,2022-01-01,2021-04-01,2021-01-01,2020-10-01,2020-09-01,2020-08-01,2020-07-01,2020-06-01,2020-05-01,2020-01-01,2019-11-01,2019-10-01,2019-09-01,2019-08-01,2019-07-01,2019-06-01,2019-05-10,2019-05-01,2019-03-01,2018-11-01,2018-09-01,2018-08-01,2018-07-01,2018-06-01,2018-05-01,2018-02-01,2018-01-01,2017-12-01,2017-08-01,2017-06-01,2017-05-10,2017-05-01,2017-03-01,2016-09-01,2016-07-01,2016-06-01,2016-02-01,2015-11-01,2015-01-01,2014-04-01-preview,2014-04-01,2014-01-01,2013-03-01,2014-02-26,2014-04'."}}}

[RomanBednar]

The only working combination I could find so far was when I set network APIVersion to 2023-07-01 and set resourceGroup parameter manually:

allowVolumeExpansion: true
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-premium
parameters:
  protocol: smb
  storageAccount: premiumacct
  resourceGroup: rbednar-mycluster-01-4c6xn-rg
provisioner: file.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate

@andyzhangx Any idea how this should be handled? Seems like GetProperties call requires resource group name, but if that's the case this patch would not help much.

[RomanBednar]

I've found a similar issue with CLI where the workaround was to add a resource group name, not sure if it might be related or if the same fix is planned for Azure SDK.

Anyway, GetProperties currently requires the resource group name, so what we could do is to load the name from cloud config earlier and add a check (resourceGroup != "") so we don't call GetProperties if it's not found.

Testing it with the same storage class I've posted in previous comment (but without resourceGroup paramenter) works fine for me.

[RomanBednar]

/unhold

[andyzhangx]

/retest

[andyzhangx]

/retest

[andyzhangx]

/lgtm
/retest

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andyzhangx, RomanBednar

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [andyzhangx]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[andyzhangx]

/retest

[andyzhangx]

/cherrypick release-1.29

[k8s-infra-cherrypick-robot]

@andyzhangx: failed to push cherry-picked changes in GitHub: pushToNamedFork is not implemented in the v2 client

In response to this:

/cherrypick release-1.29

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[andyzhangx]

/cherrypick release-1.29

[k8s-infra-cherrypick-robot]

@andyzhangx: failed to push cherry-picked changes in GitHub: pushToNamedFork is not implemented in the v2 client

In response to this:

/cherrypick release-1.29

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[andyzhangx]

/cherrypick release-1.29

[k8s-infra-cherrypick-robot]

@andyzhangx: failed to push cherry-picked changes in GitHub: pushToNamedFork is not implemented in the v2 client

In response to this:

/cherrypick release-1.29

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[andyzhangx]

/cherrypick release-1.29

[k8s-infra-cherrypick-robot]

@andyzhangx: new pull request created: #1479

In response to this:

/cherrypick release-1.29

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.