Use the Microsoft.Storage resource provider for Azure file share management operations

[wmgries]

Resource Provider
Microsoft.Storage

Description of Feature or Work Requested
Today, the Azure Files CLI commands for file share management (az storage share) go through the Azure storage data plane. This causes a number of issues for customers, most notably it means customers are unable to manage their file shares if their Azure storage account is in a vnet and the client where they are running the Azure CLI (such as their laptop) isn't - this is a very common management scenario for Azure Files. Therefore, we would like to add a new command path, az storage share-rm, that sends the file share management requests through the Storage Resource Provider (SRP) instead of through the Azure storage data plane.

We need to add a new command path for several reasons. First and most importantly, not all operations are available on the file share proxy resource object offered by SRP, by design. For example, operations to create and manage SAS tokens are not planned and are unlikely to be ever added to the file share object. Secondly, SRP is being a middle-man for file share requests - the requests they get to manage a file share are passed through to the data plane APIs (SRP has a way through customer vnets). SRP is generally believed to have less performance than the underlying data plane API. Therefore, it is strongly recommended that customers needing to do many calls against the Azure file share at once should use the data plane. Although this is not the primary thing that customers use Azure Files for today, we have to maintain this path for compatibility reasons. Finally, adopting SRP will require some significant changes to the command interface, and we would like to avoid a breaking change. Note, this change has already been done in the Azure PowerShell package - we maintain (verb-Aznoun, which goes through the data plane, and verb-AzRmnoun, which goes through SRP).

Minimum API Version Required
Microsoft.Storage 2019-06-01

Swagger Link
https://github.com/Azure/azure-rest-api-specs/blob/master/specification/storage/resource-manager/Microsoft.Storage/stable/2019-06-01/file.json

Target Date
1/13

Here's the link to the OneNote describing the change.

[yonzhan]

@Juliehzl add to S164.

[jsntcy]

@wmgries, in your description, you mentioned that "Minimum API Version Required
Microsoft.Storage 2019-06-01",

• Is this feature only supported since 2019-06-01 as I checked https://github.com/Azure/azure-rest-api-specs/blob/master/specification/storage/resource-manager/Microsoft.Storage/stable/2019-04-01/file.json and found the API spec of 2019-04-01 is very similar with 2019-06-01? Can we use 2019-04-01 api version to support this feature?

[yonzhan]

@wmgries, could you please help to confirm the question mentioned above?

[wmgries]

Hey, sorry I missed this. I don't see why you cannot use 2019-04-01, however, the control plane is missing several features currently, in both API versions, that are in plan to be added in January. Several examples: snapshot support and share stats. These will presumably use 2019-06-01 as I do not think they require breaking changes to the API.

The spec I gave does not assume this missing features are there.

[jsntcy]

@wmgries , thanks for your confirmation. We'll use 2019-04-01 for this feature and in the future, when we support features only in 2019-06-01, we'll use 2019-06-01.

Also this time for each command, CLI will not support the following options as PowerShell didn't support them yet. If we do need support them, we can support them in the future.

• We only support using "account-name", but not support "account-id".
• We will not support "ids" for the commands in spec, such as "az storage share-rm show --ids string[]>"

[wmgries]

I would argue the equivalent to account-id for PowerShell is taking in an object. For example:

$storAcct = Get-AzStorageAccount -ResourceGroupName "myRG" -Name "mysa"
New-AzRmStorageShare -StorageAccount $storAcct -Name "myshare"

CLI does let you get storage accounts by the ID of the storage account, (az storage account show --ids), so if you're in the position where you have the ID of a storage account, I don't see why you shouldn't be able to create a proxy resource with it instead of having to independently lookup the name and resource group of the resource.

Is this the only open design issue with what I proposed in the OneNote?

[jsntcy]

@wmgries, thanks for your comments.

I have set up a meeting next week to discuss the design further with you.

[jsntcy]

This feature was already released in Azure CLI 2.0.81.