Closed piotr-lasota closed 1 year ago
I assume that the issue stems from the fact that after validation the token is no longer returned by Azure. Thus during refreshing the property is not present in the response.
During validation:
$: az staticwebapp hostname list --name app-terraform-mwe
[
{
"createdOn": "2021-12-31T12:19:45.157424",
"domainName": "<domain>",
"errorMessage": null,
"id": "/subscriptions/<sub_id>>/resourceGroups/rg-terraform-mwe/providers/Microsoft.Web/staticSites/app-terraform-mwe/customDomains/<domain>",
"kind": null,
"location": "West Europe",
"name": "<domain>",
"resourceGroup": "rg-terraform-mwe",
"status": "Validating",
"type": "Microsoft.Web/staticSites/customDomains",
"validationToken": "<validation_token>"
}
]
After validation passed (validation_token
is null
):
$: az staticwebapp hostname list --name app-terraform-mwe
[
{
"createdOn": "2021-12-31T12:19:45.157424",
"domainName": "<domain>",
"errorMessage": null,
"id": "/subscriptions/<sub_id>>/resourceGroups/rg-terraform-mwe/providers/Microsoft.Web/staticSites/app-terraform-mwe/customDomains/<domain>",
"kind": null,
"location": "West Europe",
"name": "<domain>",
"resourceGroup": "rg-terraform-mwe",
"status": "Ready",
"type": "Microsoft.Web/staticSites/customDomains",
"validationToken": null
}
]
Attempt to preserve the original token via livecycle
ignore_changes
did not fix this
resource "azurerm_static_site_custom_domain" "txt-root" {
static_site_id = azurerm_static_site.website.id
domain_name = azurerm_dns_zone.dns.name
validation_type = "dns-txt-token"
lifecycle {
ignore_changes = [
validation_token
]
}
}
and still yields the same error message as in the issue description
I went with just hard-coding the validation_token
value into the "azurerm_dns_txt_record" "txt-root"
via a variable:
variable "txt_validation_token" {
description = "Manual override of the Custom Domain TXT validation token until https://github.com/hashicorp/terraform-provider-azurerm/issues/14750 is fixed"
type = string
nullable = true
default = null
}
resource "azurerm_dns_txt_record" "txt-root" {
resource_group_name = var.resource_group_name
ttl = var.ttl
record {
- value = azurerm_static_site_custom_domain.txt-root.validation_token
+ value = var.txt_validation_token != null ? var.txt_validation_token : azurerm_static_site_custom_domain.txt-root.validation_token
}
}
For the initial go the variable is null so we actually read the token (as it's available) and after the validation_token
is generated and validation is secure (and the validation_token
gone) I populate the variable with it's value manually after extracting it from the state. Not great but at least temporarily I can proceed and not have to go back to the Azure Portal
After the validation of the domain name, the TXT record can be removed. Because the validation_token is no longer there, the record can also be removed. Keeping it in the Terraform state is, I think, not necessary anymore.
Workaround
I went with just hard-coding the
validation_token
value into the"azurerm_dns_txt_record" "txt-root"
via a variable:variable "txt_validation_token" { description = "Manual override of the Custom Domain TXT validation token until https://github.com/hashicorp/terraform-provider-azurerm/issues/14750 is fixed" type = string nullable = true default = null }
resource "azurerm_dns_txt_record" "txt-root" { resource_group_name = var.resource_group_name ttl = var.ttl record { - value = azurerm_static_site_custom_domain.txt-root.validation_token + value = var.txt_validation_token != null ? var.txt_validation_token : azurerm_static_site_custom_domain.txt-root.validation_token } }
For the initial go the variable is null so we actually read the token (as it's available) and after the
validation_token
is generated and validation is secure (and thevalidation_token
gone) I populate the variable with it's value manually after extracting it from the state. Not great but at least temporarily I can proceed and not have to go back to the Azure Portal
After a few hours of debugging this same problem and assuming it was that PEBCAK, but then I discovered this GitHub issue. Thank you for posting this problem and the workaround @piotr-lasota !!! Much appreciated! β€οΈ
After the validation of the domain name, the TXT record can be removed. Because the validation_token is no longer there, the record can also be removed. Keeping it in the Terraform state is, I think, not necessary anymore.
To this point, I tried a different workaround. Since the TXT record is no longer needed after validation, and this problem only occurs after validation happens, I changed my resource to this:
resource "azurerm_dns_txt_record" "client_subdomain_validation" {
name = "_dnsauth.mydomain"
zone_name = azurerm_dns_zone.dns.name
resource_group_name = azurerm_dns_zone.dns.resource_group_name
ttl = 300
record {
value = azurerm_static_site_custom_domain.client.validation_token == "" ? "validated" : azurerm_static_site_custom_domain.client.validation_token
}
}
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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Community Note
Terraform (and AzureRM Provider) Version
Affected Resource(s)
azurerm_static_site_custom_domain
azurerm_dns_txt_record
- as a resultTerraform Configuration Files
Debug Output
Debug output Github Gist link
Panic Output
Not applicable
Expected Behaviour
I can use
plan
andapply
after successful TXT validation byazurerm_static_site_custom_domain
Actual Behaviour
As long as the TXT validation is still pending (on Azure Portal), everything works perfectly.
As soon as the validation is done:
Steps to Reproduce
terraform apply
the provided configuration fileterraform plan
orterraform apply
(even without changing anything)If you do a
terraform plan -refresh-only
then it is indicated that theazurerm_static_site_custom_domain
no longer contains thevalidation_token
.Proceeding with the refresh via
terraform apply -refresh-only
yields no improvement on the issueImportant Factoids
None that I am aware of
References
Searching for similiar issue yielded no results so I assume this one is first.