[New Resources:] `azurerm_cdn_frontdoor_route` and `azurerm_cdn_frontdoor_custom_domain`

[WodansSon]

This PR adds New Resources for azurerm_cdn_frontdoor_route, azurerm_cdn_frontdoor_custom_domain, azurerm_cdn_frontdoor_custom_domain_txt_validator, and azurerm_cdn_frontdoor_custom_domain_secret_validator - split out from #16671.

(fixes #18063) (fixes #18249) (fixes #18333) (fixes #18370) (fixes #18470)

[WodansSon]

NOTE: This PR will be horribly broken in the iterum while I work on getting the code base into shape so it can be merged into main. Please hang with me while I work out the wrinkles. 🙂

[WodansSon]

I have just confirmed that all of the newly exposed CDN Front Door resources are fully functional with this PR and are working as expected. That said, I am still refactoring the code and some of the fields/property names may change moving forward depending on PR comments. I am only mentioning this as a heads up/disclaimer for anyone who decides to build a private based on this PR for pre-release/early adopter testing purposes.

[ghost]

Hi WodansSon,

what do you think we can use this functionality with route and custom domain in Production. Or better when comes the final Release.

BR

[sebader]

@WodansSon I have done a custom build on your branch and did test it on my env in various forms. Not using the rules engine or the secret validator but pretty much all other components. Works like a charm!! :) thanks!

[sebader]

Actually, testing this I found a (related bug):

azurerm_cdn_frontdoor_origin has a field health_probes_enabled. However, that field should only exist on azurerm_cdn_frontdoor_origin_group. On the other side, the origin is totally missing a field enabled

Not sure if you want to fix this in this PR, but it needs an update :)

[WodansSon]

@sebader

Actually, testing this I found a (related bug):

azurerm_cdn_frontdoor_origin has a field health_probes_enabled. However, that field should only exist on azurerm_cdn_frontdoor_origin_group. On the other side, the origin is totally missing a field enabled

Not sure if you want to fix this in this PR, but it needs an update :)

~~It looks like this is actually a bug in the Portal UI due to the name in the API for this property, it is sort of confusing. If you look at the comments for that property in the API it states that for the Origin EnabledState property is not actually enabling/disabling the Origin itself, but rather it is enabling/disabling the health probes:~~

EnabledState - Whether to enable health probes to be made against backends defined under backendPools. Health probes can only be disabled if there is a single enabled backend in single enabled backend pool. Possible values include: 'EnabledStateEnabled', 'EnabledStateDisabled'

In the Terraform Origin Resource it is implemented like this:

props := &cdn.AFDOriginProperties{
  EnabledState:                expandEnabledBool(d.Get("health_probes_enabled").(bool)),

~~So this appears to me to be correctly implemented in the Terraform Origin resource... As for the Origin Group UI in the portal I have no idea where they are getting that value from, in the REST API there is nothing in the Origin Group that has anything related to enabled/disabled value for the health probes. I will have to investigate that a bit and get back to you on that one.~~

For the Origin resource, I did a quick experiment and this appears to be a bug in the API, I will open that shortly against the API Spec for this service. So what I will need to do to fix this is to deprecate the existing property health_probes_enabled and expose an enabled property to avoid a breaking change in the existing resource. @sebader, good catch on this one! 🚀

For the Origin Group UI in the portal this check box is controlled depending on if you have Health Probes defined in your configuration file or not, there isn't an "enabled/disable" property. If Health Probes are defined in your azurerm_cdn_frontdoor_origin_group config file the check box will show as enabled if they are not defined the check box will show as disabled. It is weird, but that is how this API currently works. 🤷‍♂️

[WodansSon]

@clemensloebig

Hi WodansSon,

what do you think we can use this functionality with route and custom domain in Production. Or better when comes the final Release.

BR

As of right now I would only suggest using a private build of this PR in a test environment as things may move a little before the final release of these bits. As for the final release I am hoping, not promising, that they will be in v3.23.0 or v3.24.0 of the official provider... let's keep our fingers crossed, there is still a lot of work to do to get these resources shipshape and Bristol fashion. 🚀

[WodansSon]

[WodansSon]

[WodansSon]

Thanks @WodansSon - LGTM outside what we discussed internally 🌵

Working on some manual test for the association resource(e.g. azurerm_cdn_frontdoor_route_disable_link_to_default_domain)... since it is a virtual resource it seems to get out of sync, but I am not sure how much I can do to correct that... doing the best that I can... 😬

[WodansSon]

[github-actions[bot]]

This functionality has been released in v3.25.0 of the Terraform Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

[github-actions[bot]]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.