Terraform-provider-azurerm: Feature request: Support log settings for app services and functions

[phekmat]

Like #756 and #1026, it would be nice to support the log configuration for app_service/slot and function_app.

See https://github.com/Azure/azure-sdk-for-go/blob/v15.0.0/services/web/mgmt/2016-09-01/web/models.go#L16146 and https://docs.microsoft.com/en-us/rest/api/appservice/webapps/updatediagnosticlogsconfig

[dijitali]

If this is looked at, it would be great to support all App Service configuration options rather than just log settings.

These are viewable in the Resource Explorer here:
https://resources.azure.com/subscriptions/<SUBSCRIPTION-ID>/resourceGroups/<RESOURCE-GROUP-NAME>/providers/Microsoft.Web/sites/<APP-NAME>/config

And documented here:
https://docs.microsoft.com/en-us/rest/api/appservice/webapps

[vidarw]

@tombuildsstuff @katbyte Any thoughs on how to name the properties for the best consistency?

[tombuildsstuff]

@vidarw presumably these'd make the most sense as nested blocks/objects (such that it matches the API) within the App Service / App Service Slot resource, but it's hard to say if they'd be better as an independent (split out) resource until it's prototyped. The other question I think is relevant here is how we'd reset these back to their default values (since there's no "delete/reset" API endpoint/method); whilst it's possible to determine what the default values are (and to submit those) - there's no guarantee those won't change over time.

Hope that helps :)

[vidarw]

When you mention default values, you refer to the scenario where first apply values and then later removes the config section from your terraform files? Is the expected behavior to return these settings to their original value?

Shouldn't it be possible to test if MS changes the default by creating a new blank resource without the log section and compare settings with the maintained list?

Something like this?

logs {
  application_file_system_log_level =  "On"/"Off" (or should we use true|false)
  application_table_storage_sas_token = "https://..." (document the ability to use the SAS data source)
  application_table_storage_log_level = "Off"
  http_file_system_retention_size = "15"
  http_file_system_retention_days = "30"
}

Other suggested names for the section _diagnostic_logs_ (after the UI) _log_settings_/_log_config_ (similar names to the other terraform sections).

[tombuildsstuff]

@vidarw since these are nested it'd be better to make these nested based on the .'s e.g.:

log_configuration {
  application_logs {
    file_system {
     level = "level"
    }
  }
  azure_table_storage {
    level=""
    sas_url=""
  }

  # ..
}

Shouldn't it be possible to test if MS changes the default by creating a new blank resource without the log section and compare settings with the maintained list?

Yes - but we'd probably want to assert that the default settings are as we expect, since these defaults can change from time to time - for example we work around this in the MySQL/Postgresql Configuration resources by submitting a "use-default-value" argument back to the API, which resets it to whatever the current default is (which could change between versions of MySQL/Postgresql)

[Workshop2]

@tombuildsstuff is there any plan to support this feature in the future?

[hdpe]

I'd be interested in picking this up if no one else is working on it, at least for the diagnostic logs bit. I think I've got a handle on the work required using the nested blocks approach described above and the very analagous work currently being done by @joakimhew on https://github.com/terraform-providers/terraform-provider-azurerm/pull/2831.

Please shout if that would not (or would) be desirable!

[BlooDCrescent]

Is this feature still being worked on?