application_logs file_system_level is not deleted from azurerm_linux_web_app

[marcindulak]

trafficstars

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 and review the contribution guide to help.

Terraform Version

1.7.5

AzureRM Provider Version

3.98.0

Affected Resource(s)/Data Source(s)

azurerm_linux_web_app

Terraform Configuration Files

resource "azurerm_linux_web_app" "this" {
  name                = "myname"
  resource_group_name = "myname"
  location            = "West Europe"
  https_only          = true

  site_config {
  ...
  logs {
    application_logs {
      file_system_level = "Verbose"
    }
    http_logs {
      file_system {
        retention_in_days = 32
        retention_in_mb   = 100
      }
    }
    detailed_error_messages = true
    failed_request_tracing  = true
  }

  lifecycle {
    ignore_changes = [
      # Ignore retention_in_days due to flakiness https://github.com/hashicorp/terraform-provider-azurerm/issues/23713
      logs[0].http_logs[0].file_system[0].retention_in_days,
     ]
  }
...
}

Debug Output/Panic Output

~ resource "azurerm_linux_web_app" "this" {
        id                                             = "/subscriptions/myname/resourceGroups/myname/providers/Microsoft.Web/sites/myname"
        name                                           = "myname"
      ~ logs {
          ...
          - application_logs {
              - file_system_level = "Verbose" -> null
            }
          ...
        }

        # (3 unchanged blocks hidden)
    }

Expected Behaviour

The file_system_level is deleted on first "terraform apply" or an error is raised.

      ~ logs {
          - application_logs {
              - file_system_level = "Verbose" -> null
            }
        }

Actual Behaviour

The deletion of the file_system_level block appears on every "terraform apply"

      ~ logs {
          - application_logs {
              - file_system_level = "Verbose" -> null
            }
        }

Steps to Reproduce

No response

Important Factoids

Setting file_system_level = "Off" also results in terraform apply not performing the change

References

Interestingly the Azure portal does not offer a way to delete or turn "Off" this "Level" setting either. This is inconsistent with https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/linux_web_app which mentions the "Off" option.

Here is how the app service "App service logs" menu looks like after file_system_level is configured using terraform apply.

The default app service "App service logs" menu does not include the "Level" setting at all.

[bison92]

Hi,

For me it does not even work. I'm using:

resource "azurerm_linux_web_app" "web_app" {
    name                = "somename"
    resource_group_name = data.azurerm_resource_group.service_rg.name
    location            = azurerm_service_plan.service_plan.location
    service_plan_id     = azurerm_service_plan.service_plan.id
    app_settings = {
        "APPLICATIONINSIGHTS_CONNECTION_STRING" = azurerm_application_insights.service_insights.connection_string
    }
    logs {
        application_logs {
            file_system_level = "Verbose"
        }
    }
    site_config {
      always_on = true
      application_stack {
        docker_image_name        = "someimage"
        docker_registry_url      = "https://someregistry"
        docker_registry_username = "someusername"
        docker_registry_password = var.docker_registry_password
      }
    }
}

and the resource is being created with FileSystem logging off.

I agree it looks a bit inconsistent with the UI, but I was thinking Off is to set the "ApplicationLogging" option off, and any loglevel would imply the "ApplicationLogging" becoming FileSystem as that is the name of the property we're using.

In any case it does not work.