Support Azure Functions Flex Consumption create and publish

[nzthiago]

Azure Functions are introducing a new hosting plan called Flex Consumption. It has significant changes in features from the current Consumption plan. This also means changes to the control plane CRUD schema of microsoft.web/sites and also for the deploy/publish endpoint.

This entry is to track adding AZD support for this hosting plan.

For the CRUD schema, this will be updated as part of the Microsoft.Web RP version 2023-12-01 as part of this PR.

For deployment, we have consolidated the deployment action into one approach where a blob storage container is configured through the control plane, and a zip file can be provided via:

• Check if the app is of the Flex Consumption SKU. For example, Azure Functions Core Tools does this with just the Azure subscription ID and the function app name :

1. Getting the function app resource id via
   POST https://management.azure.com/providers/Microsoft.ResourceGraph/resources?api-version=2022-10-01
   {
   "subscriptions": ["AZURE SUBSCRIPTION ID"],
   "query": "where type =~ 'Microsoft.Web/sites' and name =~ 'FUNCTION APP NAME' | project id"
   }

2. Get the details about the app:
   GET https://management.azure.com/subscriptions/FUNCTION APP RESOURCE ID?api-version=2023-12-01

3. Look at properties.sku. This should say FlexConsumption for Flex Consumption function apps.

• If it is a Flex Consumption app, the publish URI with the zip file should be scm_url + /api/publish
• If you are polling for the latest deployment status every 2 seconds or more, you might end up seeing 404s since kudu finishes deployment quickly and then gets recycled. So, in that case, you would need to change the polling frequency to be every second.
• For Python, add a RemoteBuild=true to the query strings. Example code from AZ CLI

[weikanglim]

Thiago Almeida (@nzthiago)

Thank you for providing the helpful context to get us started! We have a few follow-up questions from our side based on the description provided about this new endpoint $SCM_URL/api/publish:

1. Does the long-running operation from api/publish include building and running the function app, or just the upload? Another way to put it, after api/publish, what is the guaranteed state of the function app?
2. Does api/publish provide a response header, i.e. Location or OperationLocation for the status of the specific long-running operation instance (LRO)? The example code from az CLI polls on deployment/latest, but isn't guaranteed to match the exact deployment published -- in fact, we've had bugs in the past due to deployment/latest polling.
3. Do we have a sample response body for api/publish, and known success / error cases?

you might end up seeing 404s since kudu finishes deployment quickly and then gets recycled. So, in that case, you would need to change the polling frequency to be every second.

Changing the polling frequency certainly reduces the likelihood of the 404 observations, but it is still possible the client to observe the 404, which then leads to a failed deployment. Are we suggesting instead that 404s are expected as part of the polling status response?

[im-samz]

Hi Wei Lim (@weikanglim), thank you for your questions! Here are my responses for each:

1. api/publish is a method that will upload a .zip package to the Kudu SCM site. In the api/publish header, you can pass a parameter called remoteBuild. Depending on the parameter's value, Kudu will either build the contents of the .zip package - or leave it alone (assuming that the code was built before being zipped up). After this operation, the resultant .zip package will be a ready-to-run package; the platform will place this package into a storage container that is specified in the app's functionAppConfig section. Assuming there was no customer error when producing the zip package and that a successful build was done, the function app should restart and run from the newly deployed package.
2. The deployment through the endpoint will always be async. As such, it will return the deployment ID in the response. The behaviour is the same as the zipdeploy API: https://github.com/projectkudu/kudu/wiki/Deploying-from-a-zip-file-or-url#asynchronous-zip-deployment.
3. Edit: sample response is ready. See my comment below.
4. The 404 responses are a result of the polling taking too long, polling after the deployment has already completed. Ideally, we would poll at least once before the deployment completes; that will tell us that it has successfully commenced. If you observe a success first and then a 404 later, you can conclude that the deployment succeeded. This behaviour isn't ideal, and it is something we will improve in the future.

You can refer to this snippet of code of how the AZ CLI is calling the api/publish endpoint. It also includes success and failure scenarios: https://github.com/kamperiadis/azure-cli/blob/1310c61bfaafc5acab54485f7cbcaefd64b18fcf/src/azure-cli/azure/cli/command_modules/appservice/custom.py#L5560

This doc also shows a sample /api/publish call: https://microsoft.sharepoint.com/teams/AzureFunctionsTeam/_layouts/15/Doc.aspx?sourcedoc=%7B67fa1659-74e3-471a-a1b5-eb43419e31ee%7D&action=edit&wd=target%28FC%20-%20Kudu.one%7C734ffab7-e225-4056-8886-2ac7b497a179%2FAz%20CLI%20Intent-based%20deployment%20Support%7C55e09334-8981-4be0-b31d-f33d229566fc%2F%29&wdorigin=NavigationUrl

If it's more helpful, I can set up a call with you and our teams. Afterwards, I can post notes to this thread.

[im-samz]

Hi Wei Lim (@weikanglim), I have an update for your third question:

3) Do we have a sample response body for api/publish, and known success / error cases?

• The response body for api/publish is the deployment ID. For example: "3f394416-b25a-4e42-aa01-02a1f011772e"

Additionally, the response body for api/deployments/latest is as follows:
{
"id": "",
"status": <value from -1 to 6>,
"status_text": "",
"author_email": "",
"author": "",
"deployer": "postman",
"remoteBuild":<true or false, depending on what was passsed>,
"message": "",
"progress": "",
"received_time": "",
"start_time": "",
"end_time": null,
"last_success_end_time": null,
"complete": false,
"active": false,
"is_temp": false,
"is_readonly": false,
"url": "<url to https://{{scmSiteURL}}/api/deployments/"
"log_url": "<url to the latest deploymentID's logs>
"site_name": "",
"build_summary": {
"errors": [],
"warnings": [],
"logger": null
}
}

Each client tool mainly needs to consider the "status" field. Here are the possible statuses and their meanings:
-1 = Cancelled
0 = Pending
1 = Building
2 = Deploying
3 = Failed
4 = Success
5 = Conflict
6 = PartialSuccess

AZ CLI's code provides examples of how to handle each case:
https://github.com/kamperiadis/azure-cli/blob/1310c61bfaafc5acab54485f7cbcaefd64b18fcf/src/azure-cli/azure/cli/command_modules/appservice/custom.py#L5560

[pamelafox]

Is there a PR that I can follow for this? I need to update my functions to use Flex before a July 1st deadline, so I need to decide if I can wait for azd to support Flex or if I need to implement a workaround. I have a lot of functions so would obviously prefer for azd to support Flex. Thanks!

[weikanglim]

Pamela Fox (@pamelafox) The private build in #3923 should be working if you'd like to test it. We're still ironing out a few corner error handling cases.