-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VNet-injected azurerm_databricks_workspace creation fails with: SubnetIsNotWithinVnetError Subnet CIDR range '<null>' is not within the Virtual Network CIDR range #27099
Comments
Hi @dehouwerd I am unable to reproduce your problem. I can deploy the workspace fine with the configuration you posted above, with some modification related to virtual network / subnet config (refer to Modules/databricks_workspace/main.tf). I recommend checking your virtual network / subnet configuration as recommended by the error message Example of a valid subnet config that is "within virtual network CIDR range":
Note that you can also use terraform data sources to refer to existing virtual network, subnets, etc. to reduce brittleness of referring things by its string id. |
Hi @gerrytan, the provided value is correct. The apply command fails when a non-existing subnet name is provided. An API call looks to be made but the value mentioned in the response has an s appended to the output.
|
@dehouwerd there's definitely no logic in the code that appends an Can you please double check the list of subnets currently available in the virtual network? If still no luck can you please try again with a different subnet (with different name and CIDR range) ? |
@dehouwerd can you please also refer to this doc: https://learn.microsoft.com/en-us/azure/databricks/security/network/classic/vnet-inject
You did not encounter that exact error, but isolating your problem by deploying your workspace against a new pair of subnet will give us more clue towards the root cause. |
Hi everyone, facing the same issue BUT using bicep template deployment.
The parameters for the subnet names in .parameters.json are the following:
During today's deployment I am catching the following error:
The template is quite simple, and there are no code where the 's' suffix at the end of the subnet name could have appended. Both subnet with the correct CIDR are exist in the Virtual Network. |
Hi @Anton-Kalashnik88 , can you please post the virtual network configuration with Alternatively you can also raise a support request through the portal to have us investigate a specific Databricks workspace deployment. |
This is not a terraform or databricks issue. It is a Microsoft Azure Bug. This happens with vnet injection. When creating a subnet from the portal, it creates as "addressPrefixes" instead of "addressPrefix", the difference is in the plural. This causes Terraform or ARM deployment to fail because it looks for the singular, not the plural. Since it does not find it, it creates the error. I raised the issue with Microsoft. In the meantime, a temporal solution is to create the subnet using AZ CLI, this will create the subnets with the correct parameter name, and you'll be able to deploy. |
Thank you @jarteagaf , that explains why I could not reproduce the problem -- I pre-create the subnet using Terraform. @dehouwerd can you please try this recommended solution and check if it solves your problem? |
Is there an existing issue for this?
Community Note
Terraform Version
1.6.2
AzureRM Provider Version
3.115.0
Affected Resource(s)/Data Source(s)
azurerm_databricks_workspace
Terraform Configuration Files
Debug Output/Panic Output
Expected Behaviour
Succesfull resource deployment
Actual Behaviour
Terraform fails to deploy the resource. The subnet in the error message has an extra 's' appended at the end of the subnet. The resouce in the Azure portal (failed state) has the correct Custom public subnet name JSON value.
Steps to Reproduce
terraform init
terraform apply --auto-approve
Important Factoids
No response
References
No response
The text was updated successfully, but these errors were encountered: