Unable to create SQL VirtualNetworkRule due to virtual_network_subnet_id validation

[rickporter-tuono]

• Package Name: azure.mgmt.sql
• Package Version: 0.23 and 0.24
• Operating System: Mac/Linux
• Python Version: 3.7/3.8

Describe the bug
The VirtualNetworkRule creation seems to consistently fail due to incorrect virtual_network_subnet_id validation.

Always fails with LinkedInvalidPropertyId when attempting to create a VirtualNetworkRule on an Sql server. I tried several permutations of the virtual_network_subnet_id (e.g. /subscription/..., /providers/...) with and without trailing '/' on the subnet id.

The error appears to come from azure/mgmt/sql/operations/_virtual_network_rules_operations.py:206
E msrestazure.azure_exceptions.CloudError: Azure Error: LinkedInvalidPropertyId
E Message: Property id '{'virtual_network_subnet_id': '/subscriptions//resourceGroups//providers/Microsoft.Network/virtualNetworks//subnets/'}' at path 'properties.virtualNetworkSubnetId' is invalid. Expect fully qualified resource Id that start with '/subscriptions/{subscriptionId}' or '/providers/{resourceProviderNamespace}/'.

To Reproduce
Steps to reproduce the behavior:

1. Create resource group
2. Create virtual network with a subnet (with or without a Microsoft.Sql ServiceEndpoint)
3. Create an Sql server
4. Attempt to add a VirtualNetworkRule to the server using the SDK

Expected behavior
I was expecting that I would be able to create a VirtualNetworkRule on the server, similar to the way that I can do it from the GUI.

Screenshots
NA

Additional context
A couple things I noticed:

1. API version seems old
2. GUI seems to show a subnet address range when creating a VirtualNetworkRule.

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

---

Issue meta data

Issue content:	- **Package Name**: azure.mgmt.sql - **Package Version**: 0.23 and 0.24 - **Operating System**: Mac/Linux - **Python Version**: 3.7/3.8 Describe the bug The VirtualNetworkRule creation seems to consistently fail due to incorrect virtual_network_subnet_id validation. Always fails with LinkedInvalidPropertyId when attempting to create a VirtualNetworkRule on an Sql server. I tried several permutations of the virtual_network_subnet_id (e.g. /subscription/..., /providers/...) with and without trailing '/' on the subnet id. The error appears to come from azure/mgmt/sql/operations/_virtual_network_rules_operations.py:206 E msrestazure.azure_exceptions.CloudError: Azure Error: LinkedInvalidPropertyId E Message: Property id '{'virtual_network_subnet_id': '/subscriptions//resourceGroups//providers/Microsoft.Network/virtualNetworks//subnets/'}' at path 'properties.virtualNetworkSubnetId' is invalid. Expect fully qualified resource Id that start with '/subscriptions/{subscriptionId}' or '/providers/{resourceProviderNamespace}/'. To Reproduce Steps to reproduce the behavior: Create resource group Create virtual network with a subnet (with or without a Microsoft.Sql ServiceEndpoint) Create an Sql server Attempt to add a VirtualNetworkRule to the server using the SDK Expected behavior I was expecting that I would be able to create a VirtualNetworkRule on the server, similar to the way that I can do it from the GUI. Screenshots NA Additional context A couple things I noticed: API version seems old GUI seems to show a subnet address range when creating a VirtualNetworkRule.
Issue author:	rickporter-tuono
Assignees:	-
Milestone:	-

[rickporter-tuono]

It looks like this is possible, but does not follow the standard API pattern...

The VirtualNetworkRulesOperations.create_or_update() has a non-default argument for virtual_network_subnet_id, which causes the model.VirtualNetworkRule to become the virtual_network_subnet_id (instead of being maintained as the operation_config).

I was able to work around this issue.

[Karishma-Tiwari-MSFT]

Thanks for sharing the update. Please let me know if you still need any help with this.

Hi, we're sending this friendly reminder because we haven't heard back from you in a while. We need more information about this issue to help address it. Please be sure to give us your input within the next 7 days. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!