You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment
Description
I am creating my CosmosDb with Terraform and I have a few subnets available which I have configured as data in my scripts to refer in azurerm_cosmosdb_account configuration within a dynamic "virtual_network_rule" to allow multiple subnets. However these subnets do not have a pre-configured Service Endpoint and I would like to still proceed with creating CosmosDb and I would be updating the subnets separately to create necessary service endpoints. And hence it would be useful to have a flag (eg. ignore_missing_vnet_service_endpoint) same as what we have on Azure CLI - --ignore-missing-vnet-service-endpoint. It would be useful to have it either at same level as is_virtual_network_filter_enabled or within each virtual_network_rule alongside it's id attribute.
I am not sure if this is purposely omitted. On one level, it is good to know when creating CosmosDb with Subnet config, that something in the referred subnet is missing for the connectivity to fully work, but then this is different to UI and AzureCLI where we are allowed to proceed with a flag.
New or Affected Resource(s)
azurerm_cosmosdb_account
Potential Terraform Configuration
#Allow access from selected subnets only e.g. from Aks subnetis_virtual_network_filter_enabled=trueignore_missing_vnet_service_endpoint=truedynamic"virtual_network_rule" {
for_each=data.azurerm_subnet.aks_subnets_as_datacontent {
id=virtual_network_rule.value.id
}
}
or
#Allow access from selected subnets only e.g. from Aks subnetis_virtual_network_filter_enabled=truedynamic"virtual_network_rule" {
for_each=data.azurerm_subnet.aks_subnets_as_datacontent {
id=virtual_network_rule.value.idignore_missing_vnet_service_endpoint=true
}
}
References
#0000
The text was updated successfully, but these errors were encountered:
…nt (#7348)
Added support for ignore_missing_vnet_service_endpoint in virtual_network_rule within azurerm_cosmosdb_account.
Added new test case for this specific case and updated documentation.
fixes#6712
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!
ghost
locked and limited conversation to collaborators
Aug 9, 2020
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Community Note
Description
I am creating my CosmosDb with Terraform and I have a few subnets available which I have configured as data in my scripts to refer in azurerm_cosmosdb_account configuration within a dynamic "virtual_network_rule" to allow multiple subnets. However these subnets do not have a pre-configured Service Endpoint and I would like to still proceed with creating CosmosDb and I would be updating the subnets separately to create necessary service endpoints. And hence it would be useful to have a flag (eg. ignore_missing_vnet_service_endpoint) same as what we have on Azure CLI - --ignore-missing-vnet-service-endpoint. It would be useful to have it either at same level as is_virtual_network_filter_enabled or within each virtual_network_rule alongside it's id attribute.
I am not sure if this is purposely omitted. On one level, it is good to know when creating CosmosDb with Subnet config, that something in the referred subnet is missing for the connectivity to fully work, but then this is different to UI and AzureCLI where we are allowed to proceed with a flag.
New or Affected Resource(s)
Potential Terraform Configuration
or
References
The text was updated successfully, but these errors were encountered: