azurerm_cdn_frontdoor_origin_group - Health probe can't be removed

[jamesryanuk]

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

1.3.6

AzureRM Provider Version

3.34.0

Affected Resource(s)/Data Source(s)

azurerm_cdn_frontdoor_origin_group

Terraform Configuration Files

resource "azurerm_cdn_frontdoor_profile" "frontdoor_profile" {
  name                = "frontdoortest20221206"
  resource_group_name = data.azurerm_resource_group.existing_rsg.name
  sku_name            = "Standard_AzureFrontDoor"
}

resource "azurerm_cdn_frontdoor_origin_group" "frontdoor_origin_group" {
  cdn_frontdoor_profile_id = azurerm_cdn_frontdoor_profile.frontdoor_profile.id
  name                     = "frontdoororigingroup"

  health_probe { # Remove this section after creation to observe the issue
    interval_in_seconds = 240
    path                = "/healthProbe"
    protocol            = "Https"
    request_type        = "HEAD"
  }

  load_balancing {
    additional_latency_in_milliseconds = 0
    sample_size                        = 16
    successful_samples_required        = 3
  }
}

Debug Output/Panic Output

  # azurerm_cdn_frontdoor_origin_group.frontdoor_origin_group will be updated in-place
  ~ resource "azurerm_cdn_frontdoor_origin_group" "frontdoor_origin_group" {
        id                                                        = "/subscriptions/4cedc5dd-e3ad-468d-bf66-32e31bdb9148/resourceGroups/1-ffc3bbe0-playground-sandbox/providers/Microsoft.Cdn/profiles/frontdoortest20221206/originGroups/frontdoororigingroup"
        name                                                      = "frontdoororigingroup"
        # (3 unchanged attributes hidden)

      - health_probe {
          - interval_in_seconds = 240 -> null
          - path                = "/healthProbe" -> null
          - protocol            = "Https" -> null
          - request_type        = "HEAD" -> null
        }

        # (1 unchanged block hidden)
    }

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

For full debug output please see https://gist.github.com/jamesryanuk/ccfe70a4d0e0fb6380845724e4a20fdd

Expected Behaviour

The health probe should be disabled

Actual Behaviour

1. The health probe is not disabled, despite the output saying "Apply complete! Resources: 0 added, 1 changed, 0 destroyed.".
2. The next time terraform apply is run the output is the same

Steps to Reproduce

1. Create both azurerm_cdn_frontdoor_profile and azurerm_cdn_frontdoor_origin_group using the code above
2. Remove the health_probe block
3. Run terraform apply

Important Factoids

No response

References

No response

[jamesryanuk]

I attempted to fix this myself and wrote a integration test to expose the issue locally - see below for code (add to cdn_frontdoor_origin_group_resource_test.go to run). However, I can't see how to fix the issue - the implementation seems correct but the HTTP payload that is sent to the API still has the old health probe settings in it (see Gist). However, it's also likely that I'm missing something as I'm new to Go. Further direction on this would be welcome. Thanks!

func TestAccCdnFrontDoorOriginGroup_removeHealthCheck(t *testing.T) {
	data := acceptance.BuildTestData(t, "azurerm_cdn_frontdoor_origin_group", "test")
	r := CdnFrontDoorOriginGroupResource{}
	data.ResourceTest(t, r, []acceptance.TestStep{
		{
			Config: r.complete(data),
			Check: acceptance.ComposeTestCheckFunc(
				check.That(data.ResourceName).ExistsInAzure(r),
			),
		},
		data.ImportStep(),
		{
			Config: r.noHealthProbe(data),
			Check: acceptance.ComposeTestCheckFunc(
				check.That(data.ResourceName).ExistsInAzure(r),
				check.That(data.ResourceName).Key("health_probe.0.interval_in_seconds").DoesNotExist(),
				check.That(data.ResourceName).Key("health_probe.0.path").DoesNotExist(),
				check.That(data.ResourceName).Key("health_probe.0.protocol").DoesNotExist(),
				check.That(data.ResourceName).Key("health_probe.0.request_type").DoesNotExist(),
			),
		},
		data.ImportStep(),
	})
}

func (r CdnFrontDoorOriginGroupResource) noHealthProbe(data acceptance.TestData) string {
	template := r.template(data)
	return fmt.Sprintf(`
provider "azurerm" {
  features {}
}

%s

resource "azurerm_cdn_frontdoor_origin_group" "test" {
  name                     = "acctest-origingroup-%d"
  cdn_frontdoor_profile_id = azurerm_cdn_frontdoor_profile.test.id
  session_affinity_enabled = true

  restore_traffic_time_to_healed_or_new_endpoint_in_minutes = 10

  load_balancing {
    additional_latency_in_milliseconds = 0
    sample_size                        = 16
    successful_samples_required        = 3
  }
}
`, template, data.RandomInteger)
}

[rvashishth]

I am facing the same issue, i had to remove the health probe at azure portal

[WodansSon]

@jamesryanuk, thank you for opening this issue. It is an upstream Microsoft issue, where the API was not designed to be SDK friendly. The issues root cause, is that the API explicitly requires that the SDK pass a null as the health_probe attribute value. However, the SDK by default, filters out all values that are null and does not sent them to the RP. So, to fix this issue I had to hack the SDK within the provider to allow a null value to be passed to the RP for the health_probe attribute. Thanks again for this issue. 🚀

[github-actions]

This functionality has been released in v3.40.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]

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.