terraform-provider-azurerm: Terraform plan with azurerm_dns_a_record fails when parsing existing dns record with azurerm 3.19.0
Is there an existing issue for this?
- I have searched the existing issues
Community Note
- 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
Terraform Version
0.14.10
AzureRM Provider Version
3.19.0
Affected Resource(s)/Data Source(s)
azurerm_dns_a_record
Terraform Configuration Files
resource "azurerm_dns_a_record" "a_record" {
name = "dns_name"
records = [
kubernetes_service.service_name.status[0].load_balancer[0].ingress[0].ip
]
resource_group_name = "resource_group_name"
ttl = 3600
zone_name = "zone_name"
tags = local.tags
}
Debug Output/Panic Output
Error: parsing "/subscriptions/uuid/resourceGroups/resourceGroup/providers/Microsoft.Network/dnszones/dnszone/A/record": parsing segment "staticDnsZones": expected the segment "dnszones" to be "dnsZones"
Expected Behaviour
Terraform plan should finish successfully. With azurerm 3.18.0 it works fine. There where no changes to the dns config, aside from upgrading the provider version to 3.19.0
Actual Behaviour
Terraform plan fails with parsing error.
Steps to Reproduce
Run terraform plan or terraform apply with an existing dns_a_record after upgrading to azurerm 3.19.0
Important Factoids
No response
References
No response
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 24
- Comments: 24 (5 by maintainers)
We are using azurerm version 3.23.0 and faced this issue while deleting an A record. I thought this has been fixed in version 3.19.1 and shouldn’t be happening in the higher versions 🤔
I pushed a PR just now https://github.com/hashicorp/terraform-provider-azurerm/pull/18044
Still seeing this issue with 3.25.0
Issue is fixed with 3.27.0.
Same for CNAME record with provider version 3.19.0.
We’re having it with 3.26.0 as well
Hey @abreunig359
Thanks for the report and thanks to @domenicomastrangelo for the quick PR! We appreciate everyone adding context and upvoting this. We’ll have to review and test the PR to see if it fully solves the root cause of the bug, but we’ll keep everyone here updated once that’s figured out.
As far as workarounds go, I recommend downgrading to 3.18.0 if this is affecting anyones environment.