Azure-functions-host: Support appsettings.json by default.

[brettsam]

We have a lot of requests coming to allow you to use DI to call the internal ConfigurationBuilder. That can be problematic, which is why we haven't opened that up yet -- see here for example: https://github.com/Azure/azure-functions-host/issues/4464#issuecomment-513017446.

However, almost every request we have for this functionality is because we don't support appsettings.json out-of-the-box. We should be able to add that support, which should reduce the need for anyone to add their own configurations.

@fabiocav and I have talked about this a bunch but I realized there's no actual issue tracking it. So here it is.

[fabiocav]

To document some of the key challenges; Adding this support to the host is trivial, the problem we need to tackle when that happens is ensuring infrastructure components (e.g. scale controller) can load configuration from those sources, otherwise, activation and scaling may not work as expected.

[Misiu]

@brettsam @fabiocav does this mean that we will be able to access appsettings.json from functions and add/update values in it? I've created https://github.com/Azure/azure-functions-host/issues/4797 asking for such functionality but having support for appsettings.json should solve my problem.
Will you support adding/updating values in appsettings.json?

[celloist]

any update on this?

[fabiocav]

@celloist not yet. This item has not yet been assigned. We need to coordinate this change with infrastructure components to avoid issues with scaling in consumption mode. We'll keep this issue updated as/when we make progress.

[Misiu]

@fabiocav any updates?

[fabiocav]

@Misiu though the plans have been discussed and there has been some progress on identifying the work to be done to support this, the item has not yet been assigned.

We're working through prioritization to see how soon we can have this work done.
/cc @jeffhollan

[Misiu]

@fabiocav thanks for the update.
If you have any news please let us know.

[fabiocav]

@Misiu progress has been made this sprint and we expect this to land in sprint 70. Moving to reflect those plans.

[jwisener]

Any update on this?

[jwisener]

@Misiu progress has been made this sprint and we expect this to land in sprint 70. Moving to reflect those plans.

@fabiocav any status update on this?

[fabiocav]

@jwisener this is currently in PR, but has been blocked. Moving to sprint 73 to see if this is something we have the ability to deploy then.

[fabiocav]

We're now unblocked, so we should be able to merge the changes in sprint 74

[jwisener]

@fabiocav & @Misiu does that mean it's targeted such that this would be available in 2022?

[jwisener]

is there any workaround that can be done until this is released?

[andrewkittredge]

Is the issue I raised @ https://github.com/Azure/azure-functions-host/issues/5930related to this?

[gorillapower]

Is there an update on when sprint 74 will be released?

[jwisener]

@fabiocav is there any update on this? when I look at sprint 74 it’s saying 24 days past due.

[jwisener]

@brettsam and @fabiocav, We given up on this and have just wound up moving everything to azure app configuration.

[brettsam]

An update here -- the groundwork is all in (https://github.com/Azure/azure-webjobs-sdk/pull/2407, https://github.com/Azure/azure-webjobs-sdk/pull/2490, https://github.com/Azure/azure-functions-host/pull/5991) and will be released as part of our next release (which will be starting later this week, and likely take a week to roll out).

A bit of a change to the plan -- we cannot just start reading appsettings.json by default as the issue states as that could potentially affect existing customers in unexpected ways.

Instead, we've created a way to allow you to register appsettings.{environment}.json files using the FunctionsStartup class. That PR is here: https://github.com/Azure/azure-functions-dotnet-extensions/pull/33. You can see a sample of what that would look like in the SampleStartup.cs file in that PR.

Once the host release is complete, we'll merge and release the FunctionsStartup changes and publish that release on nuget.

Since all the work for this is now complete in this repo, I'm going to close this issue -- please follow along with the releases here for when this is available for use: https://github.com/Azure/azure-functions-dotnet-extensions/releases

[drdamour]

@brettsam is this something we can by default turn on in the next functions runtime major ver?

[gorillapower]

Is there any update on this? Its been almost a month but you mentioned it would part of your next release, i think we are eager to implement this as soon as possible!

[fabiocav]

@gorillapower this change is part of a release payload that took longer than expected in validation, but has been queued for deployment, which couldn't happen this week due to deployment policies preventing changes over major holidays.

We expect deployment to start early next week and will keep the linked issue updated.

[ericsampson]

@fabiocav how does this address the usecase of calling AddAzureKeyVault() in the startup code?

[fabiocav]

@ericsampson the samples posted by @brettsam in the associated issues above show how you can add custom providers at startup. Is that information sufficient?

[allenzhang83]

@fabiocav , brettsam posted a number of links. Which one is about custom provider? The SampleStartup.cs file in the link shows how to add an app.settings.json file.

[ericsampson]

@fabiocav thanks, I was just thrown off by Brett's wording above that made it sound like appsettings files was baked in somehow. When I looked at the code it should work for us :)

Is it ever going to be possible to make it so the user can add code to push parameters from the config back into the Functions host environment so that they work with the scaler (removing the "gotcha" that still exists where appsettings/KV aren't good for trigger bindings)? That would be useful for us and other people too I imagine. Thanks again!

[fabiocav]

Glad to hear that will work!

That limitation only applicable in consumption today (scenarios where the scale controller communication with the services is required). You set trigger properties in dedicated and premium with runtime driven scaling configured.

[ericsampson]

That limitation only applicable in consumption today (scenarios where the scale controller communication with the services is required). You set trigger properties in dedicated and premium with runtime driven scaling configured.

@fabiocav right, but consumption is by far the most important case for us (and probably others too) due to the massive cost savings, we try hard to only run on a fixed plan when there's already an existing one we can piggyback on.
So that's why I was wondering how hard it will be to push trigger properties from the app back into the scale controller. Thanks!

[fabiocav]

There are some challenges with that,

One (of many) is that there is no app running to push the secrets to the controller in consumption (scale to and from 0 is what gives you the consumption based billing model), and we cannot guarantee that running at deployment will give us a stable set of secrets that will not change for the life of a deployment. This also means the infrastructure will need to persist secrets customers explicitly decided to keep out of the application and environment, which would be problematic for a large number of customers. That's just to name a few of the problems that introduce reliability, privacy and other concerns in the consumption based model.

We have designs for the functionality, just not an ETA we can share at this point.

[ericsampson]

@fabiocav thanks yeah I get it. I'm glad it's being thought about. Cheers

[hermesramos]

@fabiocav is the brand new Azure Functions' appsettings.json deployed to production? Can we start using it already?