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

Feature request: Support log settings for app services and functions #1082

Closed
phekmat opened this issue Apr 5, 2018 · 11 comments · Fixed by #13046
Closed

Feature request: Support log settings for app services and functions #1082

phekmat opened this issue Apr 5, 2018 · 11 comments · Fixed by #13046

Comments

@phekmat
Copy link
Contributor

phekmat commented Apr 5, 2018

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
Copy link

dijitali commented Jun 28, 2018

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
Copy link
Contributor

vidarw commented Nov 12, 2018

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

image

@tombuildsstuff
Copy link
Contributor

@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
Copy link
Contributor

vidarw commented Nov 12, 2018

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
Copy link
Contributor

@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
Copy link

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

@hdpe
Copy link
Contributor

hdpe commented May 21, 2019

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 #2831.

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

@BlooDCrescent
Copy link

Is this feature still being worked on?

@pauska
Copy link

pauska commented Jan 27, 2021

It would be very useful to be able to enable file system application logging.

@github-actions
Copy link

This functionality has been released in v2.73.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
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 20, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
9 participants