Azure / azure-functions-host

The host/runtime that powers Azure Functions
https://functions.azure.com
MIT License
1.94k stars 441 forks source link

Overriding Configuration at Runtime for Linux Elastic Premium Plan does not work when using Environment variable with dot such as "Host.Triggers.DurableTask.AzureStorage" #8862

Open sadman-work opened 2 years ago

sadman-work commented 2 years ago

When we add the below app setting to override monitoring configuration it does not work.

AzureFunctionsJobHostlogginglogLevel__Host.Triggers.DurableTask = Warning.

Expected Behavior :

LoggerFilterOptions { "MinLevel": "None", "Rules": [ { "ProviderName": null, "CategoryName": "Host.Triggers.DurableTask", "LogLevel": "Warning", "Filter": null }

Actual Behavior:

LoggerFilterOptions { "MinLevel": "None", "Rules": [ { "ProviderName": null, "CategoryName": "Host_Triggers_DurableTask", "LogLevel": "Warning", "Filter": null }


So the . is replaced with _ for environment variable which is expected for this change done few years back.

PR 1323668

For this change host is not recognizing the environment variable as the category name to override (Host_Triggers_DurableTask versus Host.Triggers.DurableTask). The above change can't be reverted as . is not allowed character in Linux and was causing other conflicting issues.

Hence we need to make changes for the host to recognize environment variables with _ in Linux EP or Dedicated plan.

jviau commented 2 years ago

Can you elaborate on what you think we should do in this scenario? I am not sure if I see a potential solution, it just sounds like the environment does not support "." in the variable names. And for logger filters to be applied correctly you must have "." in the name.

Although IMO, it might have been better for us to not do that PR you linked and instead let the environment fail instead of giving undesired/confusing behavior to customers.

sadman-work commented 2 years ago

Can you elaborate on what you think we should do in this scenario? I am not sure if I see a potential solution, it just sounds like the environment does not support "." in the variable names. And for logger filters to be applied correctly you must have "." in the name.

Although IMO, it might have been better for us to not do that PR you linked and instead let the environment fail instead of giving undesired/confusing behavior to customers.

Adding @balag0 to comment more on why that change was done. But as far as I understood without doing that change it was cause bigger breaking issues and hence reverting that change won't be an option.

I want to discuss what is our option for the function runtime to recognize environment variables with _ .

It is a bit conflicting and hence want to see how we can fix it as we allow the customers to override configuration at runtime but if it doesn't work for Linux dedicated or Elastic Premium that can be an issue.