az cli disk update PATCH command

[TDread]

Preconditions

• No need to upgrade Python SDK or the Python SDK is ready.

Related command

az disk update --size

Resource Provider

Micxrosoft.Compute/Disks

Description of Feature or Work Requested

Currently if you use the az disk update --size against a disk that was created by azure backup. Then that operation will fail with a permissions issue if the user trying to use it does not have permission to the restore point referenced in the JSON of the disks's createdData. This is an issue with the PowerShell method of doing this as well, since they both use a PUT method and include the createdData with the PUT method.

If you only have Virtual Machine Contributor role as your RBAC and you perform a disk size change from lets say 500GB to 512GB this will work regardless on how the disk was created because it is using a PATCH method.

But if you use Azure CLI or Azure PowerShell, they both use a PUT Method. With Azure PowerShell, there is a workaround New-AzDiskUpdateConfig -DiskSizeGB 512 | Update-AzDisk -ResourceGroupName $rgName -DiskName $diskName

If you use the REST API to update the disk size then this will work, since that is only supplying the diskSizeGB parameter.

Minimum API Version Required

2023-04-02

Swagger PR link / SDK link

https://learn.microsoft.com/en-us/rest/api/compute/disks/update?view=rest-compute-2023-04-02&tabs=HTTP

Request Example

PATCH https://management.azure.com/subscriptions/{subscription-id}/resourceGroups/myResourceGroup/providers/Microsoft.Compute/disks/myDisk?api-version=2023-04-02

{
"properties": {
"diskSizeGB": 1024
}
}

Target Date

2025-03-16

PM Contact

zhoxing

Engineer Contact

thomasdread

Additional context

This originated from an issue reported that was then brought to our internal teams and I was asked to create this effort to best handle. I have the full 241 line --debug output of the azure CLI if that is needed as well.

[yonzhan]

Thank you for opening this issue, we will look into it.

[zhoxing-ms]

@TDread Due to the fact that the PUT operation currently appears to support more properties than the PATCH operation, such as zones、properties.securityProfile and so on
Do we need to consider using a new command to support PATCH operations to avoid potential breaking changes in az disk update command?

[zhoxing-ms]

@TDread In addition, as this sprint is already fully scheduled, can we postpone it to the next sprint (the release date is 04-01)?

[TDread]

If we cannot change the PUT to only provide the data points that are being asked for by the az disk update --size then it would be better to have a different azure CLI command to handle it and then updated according on public documentation for reference either of the change or the known issue.

Similar to the REST API Patch I think would be the best approach but if that can be handled in existing GET+PUT process and only filter the {BODY} to use the data points that should be modified and not the full {BODY} of the JSON payload.

Timeline isn't urgent at this point, but it would be nice to have sooner vs later.

If the best approach is the new command vs potentially breaking the old. I would agree with that as well.

[zhoxing-ms]

Similar to the REST API Patch I think would be the best approach but if that can be handled in existing GET+PUT process and only filter the {BODY} to use the data points that should be modified and not the full {BODY} of the JSON payload.

I personally think that using Patch requests in a new CLI command may be a more general solution, otherwise filtering attributes can only solve special issue case by case

[zhoxing-ms]

Timeline isn't urgent at this point, but it would be nice to have sooner vs later.

If the best approach is the new command vs potentially breaking the old. I would agree with that as well.

OK, thanks for your understanding! What do you think of the new command named az disk config update or az disk patch? Or do you have any other better suggestions?

[TDread]

Timeline isn't urgent at this point, but it would be nice to have sooner vs later.

If the best approach is the new command vs potentially breaking the old. I would agree with that as well.

OK, thanks for your understanding! What do you think of the new command named az disk config update or az disk patch? Or do you have any other better suggestions?

I think for long term the az disk config update would probably be best to mirror the https://learn.microsoft.com/en-us/powershell/module/az.compute/new-azdiskupdateconfig?view=azps-13.1.0 from the PowerShell end.