When using 'Linux' instead of 'linux' for App Service Plan, it creates a Windows App Service Plan

[pmalarme]

Bicep version
Bicep CLI version 0.6.18 (46dd19e

Describe the bug
I'm using Bicep to create a WebApp with a single container in Azure Container Registry. First I create an App Service Plan (Microsoft.Web/serverfarms@2021-03-01) using Bicep. I used a parameters JSON file to set the kind of App Service Plan I need and I put 'Linux' instead of 'linux'. When create a new deployment using Powershell, I don't receive an error but it creates instead a Windows App Service Plan meaning I cannot deploy my container anymore.

To Reproduce
main.bicep:

targetScope = 'resourceGroup'

@description('The prefix.')
param prefix string = 'helloworld'
@description('The location of the Web App to create.')
param location string = resourceGroup().location
@description('The unique name of the app service plan.')
param appServicePlanName string = 'plan-${prefix}-${uniqueString(resourceGroup().id)}'
@description('The name and tier of the app service plan.')
param appServicePlanSku object
@description('The kind of app service plan.')
param appServicePlanKind string

resource appServicePlan 'Microsoft.Web/serverfarms@2021-03-01' = {
  name: appServicePlanName
  location: location
  sku: {
    name: appServicePlanSku.name
    tier: appServicePlanSku.tier
  }
  kind: appServicePlanKind
}

main.parameters.json:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "appServicePlanSku": {
      "value": {
        "name": "F1",
        "tier": "Free"
      }
    },
    "appServicePlanKind": {
      "value": "Linux"
    }
  }
}

Command use in Local Powershell:

Connect-AzAccount
$context = Get-AzSubscription -SubscriptionName 'My-Subscription'
Set-AzContext $context
New-AzResourceGroupDeployment `
        -TemplateFile main.bicep `
        -ResourceGroupName $resourceGroupName `
        -TemplateParameterFile main.parameters.json

Additional context

[alex-frankel]

Non-intuitively, the kind property does not determine if a serverFarm uses windows or linux. You need to set the property reserved: true:

[rouke-broersma]

This makes me sad 😅

[svrooij]

This been two years, and this still makes me sad 😒 Can we not resolve this somehow? That for instance the VSCode extension (or the azure cli) will throw an error with Yes we know you want a linux machine, but you'll need to set another property as well

Or maybe even better, set the reserved property automatically if the kind is set to linux

[mennolaan]

this is indeed a terrible design flaw. Setting one parameter that actually explains what it does, but the user will be fooled regardless. What will they do if reserve is also possible for windows?

[alex-frankel]

FYI @seligj95 the description here is a little bit confusing. Wonder if we can be more descriptive here?

[seligj95]

Yes, the reserved property has been an area of confusion for a while and it's on the backlog for something we need to address. In the meantime, how do we go about updating that description? We should also add some context to the kind property for clarity there. I'll also look into adding some more guidance in our docs.

[alex-frankel]

The source for this description is here:
https://github.com/Azure/azure-rest-api-specs/blob/main/specification/web/resource-manager/Microsoft.Web/stable/2021-03-01/AppServicePlans.json#L1556

Looking at it though, this may actually be an issue with our type generation. The description has some special formatting that we don't appear to be handling correctly.

@jeskew / @anthony-c-martin can either of you take a look?

[jeskew]

The type generator is capturing the correct string, but it looks like HTML is removed in the language server. I suspect from this comment that this behavior cannot be disabled in OmniSharp, but we may be able to convert HTML comments to markdown during type generation.

[kenchon]

For those who want to know a relationship between reserved and "reserved instance":
reserved is only used to specify app service plan OS type and nothing to do with "reserved instance"

Here's what I get from Azure Support:

Q1. On the document above, it describes 'reserved' as 'If Linux app service plan true, false otherwise.'. Is it related to 'Reserved Instance' of app service plan?
Ans1: No, it's not like that we reserve an instance. This is just a property that the platform requires to understand in order to create a server farm in the backend for Linux environment, that's it.

[xandris]

I just bashed my head against this for a couple hours. Maybe deprecate reserved and give it a better name in a future API version?