Skip to content
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

imported azurerm_cdn_endpoint_custom_domain should not recreated because of Uppercase G in resourceGroups #14854

Closed
StefanSchoof opened this issue Jan 7, 2022 · 4 comments

Comments

@StefanSchoof
Copy link
Contributor

StefanSchoof commented Jan 7, 2022

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 (and AzureRM Provider) Version

Terraform v1.1.2
on windows_amd64

  • provider registry.terraform.io/hashicorp/azuread v2.14.0
  • provider registry.terraform.io/hashicorp/azurerm v2.91.0

Affected Resource(s)

  • azurerm_cdn_endpoint_custom_domain

Terraform Configuration Files

resource "azurerm_cdn_endpoint_custom_domain" "frontend_domain" {
  name            = replace(local.portal_url, ".", "-")
  cdn_endpoint_id = azurerm_cdn_endpoint.frontend_endpoint.id
  host_name       = local.portal_url
  cdn_managed_https {
    certificate_type = "Dedicated"
    protocol_type    = "ServerNameIndication"
    tls_version      = "TLS12"
  }
}

Debug Output

Terraform will perform the following actions:

  # azurerm_cdn_endpoint_custom_domain.frontend_domain must be replaced
-/+ resource "azurerm_cdn_endpoint_custom_domain" "frontend_domain" {
      ~ cdn_endpoint_id = "/subscriptions/<snip>/resourceGroups/<snip>/providers/Microsoft.Cdn/profiles/<snip>dev-cdn/endpoints/<snip>dev" -> "/subscriptions/<snip>/resourcegroups/<snip>/providers/Microsoft.Cdn/profiles/<snip>dev-cdn/endpoints/<snip>dev" # forces replacement
      ~ id              = "/subscriptions/<snip>/resourceGroups/<snip>/providers/Microsoft.Cdn/profiles/<snip>dev-cdn/endpoints/<snip>dev/customDomains/<snip>" -> (known after apply)
        name            = "<snip>"
        # (1 unchanged attribute hidden)


      - timeouts {}
        # (1 unchanged block hidden)
    }

Plan: 1 to add, 0 to change, 1 to destroy.

Panic Output

Expected Behaviour

After importing a existing azurerm_cdn_endpoint_custom_domain and a matching terraform config, an apply will not try to recreate the azurerm_cdn_endpoint_custom_domain. An case change in G of resourceGroups should be ignored.

Actual Behaviour

terraform want to destroy and recreate the azurerm_cdn_endpoint_custom_domain, because the existing resource has an Uppercase G in the endpoint_id in the /resourceGroups/ and the new should be have a lower case /resourcegroups/.

To acualy delete a custom domain, the DNS CName must removed before and added again after the destroy.

A workaround is to use lifecycle ignore_changes for the cdn_endpoint_id:

  lifecycle {
    ignore_changes = [
      cdn_endpoint_id
    ]
  }

Steps to Reproduce

  1. Create an azure cdn enpoint custom domain by hand (needs a cname entry)
  2. Create a config for azurerm_cdn_endpoint_custom_domain
  3. Import this in tf
  4. tf apply

Important Factoids

References

@magodo
Copy link
Collaborator

magodo commented Jan 11, 2022

@StefanSchoof Sorry that I can't reproduce this in my local. I've created every resource from Terraform, then create a endpoint custom domain and import it as you stated via Terraform and eveything works fine.

I'd like to know how do you create the azurerm_cdn_endpoint, did you have it in a long term but never refreshed, or did you also imported it, but with the incorrect case for G when running terraform import?

Also please check the terraform.tfstate file to see what schema_version is the azurerm_cdn_endpoint? E.g. in my case it is as below:

    {
      "mode": "managed",
      "type": "azurerm_cdn_endpoint",
      "name": "test",
      "provider": "provider[\"registry.terraform.io/hashicorp/azurerm\"]",
      "instances": [
        {
          "schema_version": 1,
          ...
        }
       ]
     }

@magodo magodo added question and removed bug labels Jan 11, 2022
magodo added a commit to magodo/terraform-provider-azurerm that referenced this issue Jan 11, 2022
Normalize the ID using the importer function to conform to what is
defined in the ID formatter.

This is to mitigate cases like users import resource ID with lowercase
'g' for the resource group. In this case, the current validation in the
importer raise no error, which results into the incorrect cased ID leak
into terraform state. This will cause the other referencing resource get
unexpected plan diff (see hashicorp#14854).

This commit adds the helper function for both untyped and typed sdk. The
users are expected to pass in a wrapper function around the parse
function generated via the resource id tool. While this wrapper might be
eliminated once we have generic in Go.
@StefanSchoof
Copy link
Contributor Author

StefanSchoof commented Jan 11, 2022

Thanks for your work.

I found that much differences in our stages, because we did not use tf for the custom domain previously (a little reminder, that I should always go the extra mile, to have everything in IoC ;) ), that I recreated the custom domain that was affected. I did not think about that this may be needed to get more info for this bug. Sorry.

the import was done by the command (found it in my shell history):

terraform import azurerm_cdn_endpoint.frontend_endpoint /subscriptions/<snip>/resourcegroups/<snip>-frontend/providers/Microsoft.Cdn/profiles/<snip>dev-cdn/endpoints/<snip>dev

@magodo
Copy link
Collaborator

magodo commented Jan 11, 2022

@StefanSchoof Thank you for confrimation 👍 Meanwhile I've submit a PR #14891, which should hopefully mitigate your incorrect import automatically.

@github-actions
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 11, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants