Make it possible to set/retrieve function app keys via ARM templates.
This will make it easier to store it in the settings of an other service while rolling out an environment.25 votes
We agree this needs to happen and we’re figuring out the best path forward.
Azure Functions currently supports Open API (Swagger 2) (https://azure.microsoft.com/en-in/updates/announcing-azure-functions-open-api-swagger-support-preview/).
Now that Open API 3 has been released, it would be helpful if the latest standard could also be supported16 votes
Thanks for the feedback!
We’re planning to add the option to support openAPI 3
I’ve added a github issue to track the work item.
Azure Functions team
Currently if you deploy your function on a consumption plan there is no way to move it to an existing Service Plan like any other App Service.
You would need to delete the existing one and redeploy it..15 votes
Quick update here – with the announcement of the premium plan we do support moving from consumption to a premium plan. Today this may not work for all consumption apps in a region only because some consumption apps may exist in a “webspace” that doesn’t yet have premium turned on. That said we have CLI commands rolling out in the next few weeks to make this seamless.
Moving to app service plan is a bit trickier as the actual code often lives in a different place on an app service plan (app service local storage) than where consumption needs them (azure storage files) – so moving may not work and currently don’t have any immediate plans to do like “code migration” in addition to changing plans.
You can see a sample of moving plans between apps in this sample here as well: https://github.com/Azure-Samples/functions-csharp-premium-scaler
Don't 'hardcode' the storage account connection string for the storage account that backs azure functions
Currently each Function App has an application setting string "WEBSITE_CONTENTAZUREFILECONNECTIONSTRING"which is a fixed (=hardcoded) connection string. This breaks when performing key rotation on the connection string and is opaque to diagnose since that setting is automatically setup by the portal UI/wizard.
Can you instead just store the subscription ID and storage account name and then fetch the latest connection string for the storage account using the management API? This will make sure that the function app survives storage account key rotations13 votes
This makes sense. We are working on solutions to enable storing the secret in Key Vault and account for rotation. There is some additional validation logic that needs to be relaxed to enable these scenarios.
This is planned. Thought there was another issue to merge with but couldn’t find it – so keeping this for now.
Azure Functions has been great, especially the ability to run the Core Tools locally. However, there are often scenarios where you return data depending on the currently authenticated user. This appears to be supported in Azure Functions in Azure now but there are no options within the Core Tools. This would be hugely useful for local development.7 votes
This is something we’re looking to enable.
Want to be able to enable Application Insights via the azure cli when creating a function without having to rely on an ARM template.
I want to be able to enable Application Insights via the azure cli when creating a function without having to rely on an ARM template. It seems like all you should have to do is have an option to say enable it and an option to state location information.4 votes
We are adding this control to our CLI soon. In the meantime you can use the simple CLI commands outlined here: https://github.com/MicrosoftDocs/azure-docs/issues/27964
Those commands should be in the App Insights docs soon.
thanks for the feedback!
This would make it much easier to work with authenticated users and interact with their information3 votes
This is something we’re working on.
If no function is present in a Function App, the “getting started” assistant is shown which allows adding a premade function. However, you can’t specify a name for the resulting function there, which is why you’ll end up with insignificant names such as “HTTPTriggerCSharp1” or “HTTPTriggerJS1”. It would be great if the user could optionally specify a function name in this dialog.2 votes
This makes sense. We’ll add it to the backlog.
The Microsoft sample documentation (link below) suggests using a Run method with void return type. This doesn't allow convenient handling of errors that you want to handle by getting EventGrid to retry invoking the Azure Function again after a period. For example, my Azure Function sends a message to a server (Azure Container Instance) which may be down. In this situation I want EventGrid to invoke my Azure Function again after a period when the server might be up. However, with a void return type my only option seems to be that of throwing an exception (InvalidOperation?). Agreed, I could use Run([(HttpTrigger(…)]…). However, what's the point of having [EventGridTrigger] if it's not going to be used?
By the way, I tried using a return type of HttpResponseMessage with Run[EventGridTrigger] and whilst it built, it reported an error at runtime Cannot bind parameter '$return' to type HttpResponseMessage&.
public static void Run([EventGridTrigger]JObject eventGridEvent, TraceWriter log)
The Microsoft sample documentation (link below) suggests using a Run method with void return type. This doesn't allow convenient handling of errors that you want to handle by getting EventGrid to retry invoking the Azure Function again after a period. For example, my Azure Function sends a message to a server (Azure Container Instance) which may be down. In this situation I want EventGrid to invoke my Azure Function again after a period when the server might be up. However, with a void return type my only option seems to be that of throwing an exception (InvalidOperation?). Agreed, I could…1 vote
Have plans to use queues behind the scenes which would add some durability
- Don't see your idea?