Azure-sdk-for-js: autoBackupSettings not found on Microsoft.SqlVirtualMachine/sqlVirtualMachines

[hdavidzhu]

• Package Name: @azure/arm-sqlvirtualmachine
• Package Version: @azure/[email protected]
• Operating system: linux
• [x] nodejs
  
  
  
  • version: v12.16.1
  
  
• [ ] browser
  
  
  
  • name/version:
  
  
• [x] typescript
  
  
  
  • version: Version 4.0.2
  
  
• Is the bug related to documentation in
  
  
  
  • [ ] README.md
  
  
  • [ ] source code documentation
  
  
  • [X] SDK API docs on https://docs.microsoft.com
  
  

Describe the bug
A clear and concise description of what the bug is.

SQLVirtualMachine.autoBackupSettings is not present. I provisioned a test Azure SQL server on VMs and can see my SQL VM using await sqlVMClient.sqlVirtualMachines.listByResourceGroup(resourceGroupName).

I configured the VM's auto backup like this:

I'm unable to see this info from the API results.

To Reproduce
Steps to reproduce the behavior:

1. Provision a new Azure SQL server for Virtual Machines
2. Set the the client
3. Get a list of VMs (using listByResourceGroup)
4. See that autoBackupSettings is not a property on the returned results:

{
  "id": "/subscriptions/<REDACTED>/resourceGroups/<REDACTED>_group/providers/Microsoft.SqlVirtualMachine/sqlVirtualMachines/<REDACTED>",
  "location": "westus",
  "name": "<REDACTED>",
  "provisioningState": "Succeeded",
  "sqlImageOffer": "SQL2019-WS2019",
  "sqlImageSku": "Developer",
  "sqlManagement": "Full",
  "sqlServerLicenseType": "PAYG",
  "type": "Microsoft.SqlVirtualMachine/sqlVirtualMachines",
  "virtualMachineResourceId": "/subscriptions/<REDACTED>/resourceGroups/<REDACTED>_group/providers/Microsoft.Compute/virtualMachines/<REDACTED>"
}

Expected behavior
A clear and concise description of what you expected to happen.

vm.autoBackupSettings.retentionPeriod should show 20 days.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

[msftbot[bot]]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @azureSQLGitHub.

[qiaozha]

I can also repro this in Azure CLi. looks like the service backend list result has missed the autoBackupSettings. add service-attention label.

[NivedhaChellam]

1. Get SQL VM List by Resource Group call returns the list of SQL VM in the resource group.
2. To get the properties of individual SQL VM, Please use Get SQL Vm call

1. With Expand call : will return the autoBackupSettings, GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.SqlVirtualMachine/sqlVirtualMachines/{sqlVirtualMachineName}?$expand=autoBackupSettings&api-version=2017-03-01-preview,

[NivedhaChellam]

@qiaozha I understand that json lists the entire properties of the SQL VM https://github.com/Azure/azure-rest-api-specs/blob/master/specification/sqlvirtualmachine/resource-manager/Microsoft.SqlVirtualMachine/preview/2017-03-01-preview/sqlvm.json#L1456. However the List operation do not include the Properties to get that we need to make another call for that specific VM.

[NivedhaChellam]

@qiaozha Autobackup settings is pulled in via expand as it is extension level property. Since, it is not stored in Metadatastore it is costly to expose such properties on GET calls. ListByResourceGroup falls in similar territory where we only want to return properties stored in Metadatstore vs making a call to Compute extensions.

[qiaozha]

@hdavidzhu Does the solution of get the autobackup settings via GET calls work for you?

[hdavidzhu]

It's not ideal, b/c we perform regular scans on this endpoint. So individual API calls would also be expensive on our end. For now, the feature I'm building is ignoring this field, and we likely won't pull it in if its expensive.

At a minimum, I'd love it if the documentation calls this out, as it's not clear by this or in the generated types that this property won't show up on listByResourceGroup!

Alternatively:

Autobackup settings is pulled in via expand as it is extension level property. Since, it is not stored in Metadatastore it is costly to expose such properties on GET calls. ListByResourceGroup falls in similar territory where we only want to return properties stored in Metadatstore vs making a call to Compute extensions.

It would be cool if this info is cached onto the Metadatastore so that we can read it via listByResourceGroup and other list commands.

Thanks folks for taking a look 🙌

[NivedhaChellam]

We understand your concern, we would definitely update the document. We would consider and discuss about the option of having extension properties also in Metadatastore internally.

[NivedhaChellam]

@qiaozha we have created the repair item to update the document. We would triage and prioritize to amend the document.

[NivedhaChellam]

@qiaozha if we are agreed upon the action item around documentation, I would recommend to close the issue.

[bluefooted]

@qiaozha Are we OK to close this now? @NivedhaChellam has created a repair item for us to update the document.

[qiaozha]

@bluefooted added need author feedback label. which will automatically close this issue if the issue author doesn't have any objections in 7 days.

[hdavidzhu]

Just so I understand, this will be in-the-works? Looking at the docs just now, I don't see it updated.

Thanks!

[bluefooted]

@hdavidzhu Yes we have filed an internal tracking item to get the documentation updated.