Azure / Azure/azure-cli

az functionapp list runtimes does not return desired information for Windows

Open
#28,298 1 comment 0 reactions 4 assignees Claimed by @kamperiadis View on GitHub
act-observability-squad Auto-Assign Functions Service Attention
Dominant language
Python
Stars
4.6k
Forks
3.5k
Avg merge
3d 2h
Merged PRs (30d)
60

Description

**Related command**
`az functionapp list-runtimes --os "windows" --query "[?runtime == 'dotnet-isolated']"`

The specific parameters are an example. there to illustrate the point.

**Is your feature request related to a problem? Please describe.**
The output of the above command today is as follows:
> [
{
"runtime": "dotnet-isolated",
"supported_functions_versions": [
"4"
],
"version": ".4.8"
},
{
"runtime": "dotnet-isolated",
"supported_functions_versions": [
"4"
],
"version": "8"
},
{
"runtime": "dotnet-isolated",
"supported_functions_versions": [
"4"
],
"version": "7"
},
{
"runtime": "dotnet-isolated",
"supported_functions_versions": [
"4"
],
"version": "6"
}
]

This has a few issues. First, it does not describe required information. Contrast with the same command, but with "linux" instead of "windows". You will see `linux_fx_version` in the response, which can be used for configuring the app. However, other settings may be required in Windows, and for "dotnet-isolated" here, I'm primarily looking for the value of `netFrameworkVersion`. This will inform a later `az functionapp config set`. I happen to know the format of this (e.g., "v8.0"), but someone who did not might encounter an issue on the next step of a common operation.

Perhaps more critically, these are not surfacing end-of-support dates which are present in the backing Stacks API. The tool should provide users with this information so that they do not select a version that is nearing or out of support.

Tangentially, it's also weird that .NET Framework 4.8 comes back as ".4.8" with that extra leading '.' which is not present in the underlying Stacks API.

**Describe the solution you'd like**
I can see from the code that something has been attempted around this before:
https://github.com/Azure/azure-cli/blob/88165864f95eb311db905f16d133b92bf9671070/src/azure-cli/azure/cli/command_modules/appservice/custom.py#L3337-L3344

Granted, those names have been normalized to be more python-ic rather than reflecting what they look like in the API or the CLI (also true of `linux_fx_version`). Regardless, none of the requisite values make it through. The code comment about getting support from the API is valid, but the information is definitely present in property bags which could simply be surfaced. See the following from the Stacks API: `siteConfigPropertiesDictionary`, `appSettingsDictionary`, `endOfLifeDate`

**Describe alternatives you've considered**
A user would otherwise need prior external knowledge of the properties and formats needed to configure the app properly for the stack should they be performing any upgrade operations. They would need to know the end of support dates from another source.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.