Open ericjohnson2 opened 3 years ago
I'm 99% certain it's related to what we're trying to partially address with #9357. As soon as that one is merged, hopefully the release after that will fix sorting of the properties. As it is now such advanced terraforming of frontdoor leads to these sad results.
Yeah, I am also facing the same issue. Hoping to get this resolve when #9357 gets merged.
@WodansSon, I think https://github.com/terraform-providers/terraform-provider-azurerm/pull/11456 will address this issue as well. Once v2.58.0 is released I can test and update.
@WodansSon, I think #11456 will address this issue as well. Once v2.58.0 is released I can test and update.
@ericjohnson2 I absolutely think that 11456 will address this issue... lmk π
This is still an issue with 2.58.0
I tried to force dependency with depends_on
as a long shot, as expected that did not work. This issue takes longer to manually resolve now that Azure requires you to delete all associated CNAME records in order to completely destroy a Front Door
instance π¦
edit: as noted in the #11456 comments you can get around this for now by hard coding
Related issues: #11857 #11348
Is there are any updates or plans regarding this issue? We facing the same problem, so it's not possible to add or change the existing frontendendpoint, without removing azurerm_frontdoor_custom_https_configuration, because azurerm_frontdoor_custom_https_configuration doesn't track upcoming changes from the frontendpoint resources and as result, we need to comment all azurerm_frontdoor_custom_https_configuration resources, apply changes to frontendendpoints and after deploy azurerm_frontdoor_custom_https_configuration. If azurerm_frontdoor_custom_https_configuration will evaluate upcoming changes to frontendendpoints.
+1 here. Can't believe it took me this long to find this thread. I've been wrenching on this for FAR longer than I'd like to admit and I've come to the same conclusion.
frontend_endpoint_id is jacked up for new frontend_endpoints
I just hit this issue now as well... Added a new endpoint, and running into a wall. I have my terraform deployments all setup in ADO pipelines... but what seems to have worked for now, is running targeted plan/apply for the FD instance to force it pickup and apply the endpoint.. then a plan/apply again which will pickup the remaining custom https configurations .. at which point, the new FD endpoint is visible
I have the same problem this is not fixed nor is it part of any other PR just spent hours browsing through github problems. Needs fixing.
Community Note
Terraform (and AzureRM Provider) Version
Affected Resource(s)
azurerm_frontdoor_custom_https_configuration
azurerm_frontdoor
Terraform Configuration Files
Module
Module Usage
Debug Output
Panic Output
Expected Behaviour
Initial creation of frontdoor with custom https configuration works.
Adding a new
frontend_endpoint
should be added to thefrontdoor
resource and the custom https configuration should be createdActual Behaviour
Initial creation of frontdoor with custom https configuration works.
Adding a new
frontend_endpoint
causesThe frontend_endpoint.id is set to
null
Steps to Reproduce
Create
frontdoor
with a fewfrontend_endpoints
that use theazurerm_frontdoor_custom_https_configuration
to do the custom frontend configuration. Using the samefrontdoor
, add an additionalfrontend_endpoint
with aazurerm_frontdoor_custom_https_configuration
. Perform aplan
after you have added the additional endpoint.terraform apply
frontdoor and custom https configterraform plan
plan
will fail on the custom https configurationImportant Factoids
none