[wiki] Confirm instructions for opting out of v2->v3 upgrade for Linux Consumption

[maximivanov]

Investigative information

• Function App name: azfuncnodever-function-app-linux-consumption
• Region: East US

Repro steps

1. Create a Linux Consumption function app
   1. FUNCTIONS_EXTENSION_VERSION=~2.0 app setting.
   2. Language: Node.js.
   3. linuxFxVersion is not set explicitly
2. Check host information via https://<func app name>.azurewebsites.net/admin/host/status?code=<master key>

Expected behavior

According to documentation, ~2.0 should opt me out of the upgrade. In the returned JSON I should see

...
"version": "2.0.xxxxx.x"

Actual behavior

v3 runtime is used:

...
"version": "3.0.14916.0",

[pragnagopa]

@divyagandhisethi - Please take a look why pinning to V2 is not working for this App.

[maximivanov]

I'll keep the App running for you to investigate. Let me know if you need anything.

[divyagandhisethi]

@maximivanov Can you please update your linuxfxversion to "Node|8" and retry?

[maximivanov]

@divyagandhisethi I can confirm that after setting linux_fx_version = "node|8" in the configuration the runtime switched from 3.0.14916.0 to 2.0.14786.0.

I'm using Terraform templates to deploy the infra and until not long ago I didn't even specify the linux_fx_version config in my scripts (since it's not required). Note that if it's missing, Node.js version will default to 10.x, not 8.x.

I'm curious what does it all mean? (my intention with this function app is not to simply make it work but to understand the logic of runtime upgrade process for a blog post I'm writing). It seems that if linux_fx_version is not provided, it leads to unexpected behavior (like ~2.0 pinning not working). Does it mean there's a bug in runtime selection logic in Azure that should be fixed? Or does it mean linux_fx_version config must be required when creating Linux apps? Thanks!

[divyagandhisethi]

Hi @maximivanov . Thanks for trying this out. I can share more details about how the runtime version is selected.

Linux function apps have a linux fx version site config, which is used to specify the language version for the app. We introduced this language version selection capability for linux apps couple of years ago. Before that, Linuxfxversion site config
was an empty string and all linux function apps were only on one version( All linux python apps were on version 3.6, node apps were on ~8). When we introduced version selection, for backward compatibility, all apps with empty LinuxFxVersion were considered legacy apps, and they will bypass version selection logic.

The current experience is that all clients(portal, CLI etc.) set the Linuxfxversion config while creating a Linux function app. Customers using ARM templates or terraform templates also need to specify the LinuxFxVersion site config while creating the function app. This requirement has been in place for more than a year now.

Since your app did not have Linuxfxversion set, it was considered as a legacy app. This in turn caused it to skip version selection. I have updated the opt-out instructions as well. Hope this clears things up. Let me know if you have any other questions.

[maximivanov]

Hi @divyagandhisethi. Thanks for the details! A bit of history and the reasoning for technical decisions is always greatly appreciated.

If I understand it correctly there's a check in the resource manager API which prevents newer function apps to be created with empty LinuxFxVersion setting (no matter which tooling calls the API). In my case, the app in question is not from years ago, I created it earlier this week. If you're saying it had LinuxFxVersion empty when you first checked, something seems to be off.

Since linux_fx_version config is optional in Terraform, and considering you said it should be required by the API, I thought maybe Terraform sets some default value... but I couldn't find anything in the Function App resource sources in TF.

Also, I wonder if it's related to this issue: Azure/azure-cli#15171 (opened by you 😄 )

To make it simpler to debug, here's the repo with minimal Terraform script to reproduce the issue (you can run it from VS Code with no extra dependencies): https://github.com/maximivanov/repro_Azure_azure-functions-host_issues_7176.

Let me know if you need anything.

[pragnagopa]

Since linux_fx_version config is optional in Terraform, and considering you said it should be required by the API, I thought maybe Terraform sets some default value... but I couldn't find anything in the Function App resource sources in TF.

There is planned work to expose valid values for linux_fx_version for each runtime version we support via ARM API. We will plan to update documentation as well.

[divyagandhisethi]

Hi @maximivanov . Thanks for the repro. I agree, I think we should update Terraform to set default values for Linuxfxversion if the user does not explicitly set it. This behavior will also align with what other clients. Let me see how we go about doing that.

As for Azure/azure-cli#15171, that is unrelated to this issue. For now, your app should be fixed since you have set Linuxfxversion.

[maximivanov]

Thanks for pushing this forward!

One more thing, the function app deployed from the repro above has empty LinuxFxVersion which results in Node.js version 10.23.1, not 8.x. Not sure if it's expected since you mentioned legacy apps were to default to 8.x. The repro has a step of verifying Node.js version in the README.

[peter-dtcats]

I am unable to create a Azure Function App from Azure CLI. Is it a bug?

ERROR: The parameter LinuxFxVersion has an invalid value.

Great If someone can throw some light on how do i specify the LinuxFxVersion through Azure CLI.

[divyagandhisethi]

@Francisco-Gamino to help with AZ powershell cmdlets

[Francisco-Gamino]

Hello @divyagandhisethi and @peter-dtcats -- In the Az.Functions cmdlets we set the LinuxFxVersion value during function app creation. However, we do support setting the LinuxFxVersion to a given value. Adding @gzuber to see if this is possible via the Az CLI.