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

azurerm_app_service blocks not working as expected #4151

Closed
darren-johnson opened this issue Aug 26, 2019 · 3 comments
Closed

azurerm_app_service blocks not working as expected #4151

darren-johnson opened this issue Aug 26, 2019 · 3 comments

Comments

@darren-johnson
Copy link

darren-johnson commented Aug 26, 2019

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 v0.12.6
provider.azurerm v1.33.0

Affected Resource(s)

  • azurerm_app_service

Terraform Configuration Files

  dynamic "connection_string" {
    for_each = "${var.configure_connection_string != "true" ? [] : [1]}"
    content {
      name  = "${var.connection_string_name}"
      type  = "${var.connection_string_type}"
      value = "${var.connection_string_value}"
    }
  }

Expected Behavior

When setting configure_connection_string to "false" the configuration is removed after querying state.

Actual Behavior

The existing connection_string remains in place. Terraform apply completes successfully. Please note if the connection_string is never configured the configuration applies successfully. Terraform actually says it is going to remove the configuration as part of an apply, but it don't remove it and leaves it in state. This is repeatable on other blocks within this resource too.

@adamday2
Copy link
Contributor

adamday2 commented Sep 12, 2019

I've noted the exact behavior on an identity block for azurerm_virtual_machine so believe that this may not be specific to this particular resource type.

Might be related to this:
hashicorp/terraform#22605

@tombuildsstuff
Copy link
Contributor

hi @darren-johnson

Thanks for opening this issue.

The Azure API supports setting the app_settings and connection_string blocks at either the top-level App Service or within an App Service Slot, which can be made active and as such override the settings at the top level App Service. In order to support this use-case in Terraform both of these blocks are marked as 'Computed', which means that if a users configured values for them then we'll use those values, however if they have no values configured then we'll use whatever's returned from Azure.

Whilst this allows us to support both use-cases unfortunately this means that to be able to clear these settings you need to explicitly define the app_settings and/or connection_string blocks with an empty array; for example:

...

resource "azurerm_app_service" "test" {
  name                = "example-appservice"
  location            = "${azurerm_resource_group.test.location}"
  resource_group_name = "${azurerm_resource_group.test.name}"
  app_service_plan_id = "${azurerm_app_service_plan.test.id}"

  app_settings = []
  connection_string = []
}

Would you be able to take a look and see if that works for you? Since this is an intentional behaviour rather than a bug in the Azure Provider I'm going to close this issue for the moment - but please let us know if that doesn't work for you and we'll take another look.

Thanks!

@ghost
Copy link

ghost commented Mar 29, 2020

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks!

@ghost ghost locked and limited conversation to collaborators Mar 29, 2020
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