Provider 3.0+ azurerm_application_gateway is enforcing a health probe body

[LWNetworks]

Is there an existing issue for this?

• [X] I have searched the existing issues

Community Note

• Please vote on this issue by adding a :thumbsup: 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

Description

Previously, within Application Gateways, the Health Probe had 2 ways or marking a backend as healthy.

1 way is the HTTP status code returned from the backend (most commonly 200) , the other, e..g to verify that content was actually on the server properly was Response Body. So if the backend webpage said 'Lorem Ipsum Dolar' on it, you could use that to mark the backend as healthy.

With provider 3.0 it appears that this has been made a required feature, which was previously an optional feature. The Azure portal still has this as an optional field.

For some of our backends, we don't want response body and just use the HTTP status code. This means we cannot use Provider 3.0+ with this new change

New or Affected Resource(s)/Data Source(s)

azurerm_application_gateway

Potential Terraform Configuration

No response

References

https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/application_gateway#body

[enorlando]

We are also encountering this issue with all our application gateway deploys. We use only the HTTP response status code match for health probes and do not intend to use HTTP response body match. In one scenario our site uses a 302 redirection, it only has response header which contains Location information to indicate the new URL, and no response body information.

HTTP response body match field is optional in the UI and should not be necessary since some websites may not have this

[enorlando]

Do we have any insights on this? Unfortunately we cannot continue with this version 3 major upgrade until this has been fixed. Thanks

[techsun]

Same issue. Had to add an ignore_changes block to move forward. This is obviously not optimal and presents risk. And since it is a TypeSet(?), the entire probe block has to be ignored. Could not find a way to ignore properties that exist within the probe.

  lifecycle {
    ignore_changes = [ probe ]
  }

[enorlando]

Do we have any update on this? We have continued on with the version 3 upgrade by ignoring the probe properties (thank you @techsun) but this is not really the best option.

[mahalel]

Also encountering this. This is a disparity between the Portal and terraform.

• Portal:

• Provider:

[nbjohnson]

We have also run into this issue where we only want to set the HTTP response code check, if we can get terraform to match the portal behavior as soon as possible that would be greatly appreciated

[github-actions[bot]]

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