azurerm_app_service_plan replaces Linux App-Plans on every apply

[bufanda]

Hi there,

I tried to terraform a Linux FunctionApp using the AzureRM Provider v1.34.0 and terraform 0.12.8.

Here the configuration

resource "azurerm_app_service_plan" "myAppPlan" {
  name                = "myAppPlan"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  kind                = "Linux"
  reserved            = true
  sku {
    tier = "Dynamic"
    size = "Y1"
  }
}

With this I created the App-Serviceplan and following my App and even though the App is working if I reapply terraform, I got changes for the App-Serviceplan which requires a replacement.

 # azurerm_app_service_plan.myAppPlan must be replaced
-/+ resource "azurerm_app_service_plan" "myAppPlan" {
      + app_service_environment_id   = (known after apply)
      ~ id                           = "/subscriptions/.../myAppPlan" -> (known after apply)
      - is_xenon                     = false -> null
      ~ kind                         = "functionapp" -> "Linux" # forces replacement
        location                     = "westeurope"
      ~ maximum_elastic_worker_count = 1 -> (known after apply)
      ~ maximum_number_of_workers    = 0 -> (known after apply)
        name                         = "myAppPlan"
      ~ per_site_scaling             = false -> (known after apply)
        reserved                     = true
        resource_group_name          = "rename"
      ~ tags                         = {} -> (known after apply)

      ~ properties {
          + app_service_environment_id = (known after apply)
          ~ per_site_scaling           = false -> (known after apply)
          ~ reserved                   = true -> (known after apply)
        }

      ~ sku {
          ~ capacity = 0 -> (known after apply)
            size     = "Y1"
            tier     = "Dynamic"
        }
    }

And the App itself will be replaced too and here the kind is set to functionapp,linux

# azurerm_function_app.myApp must be replaced
-/+ resource "azurerm_function_app" "myApp" {
      ~ app_service_plan_id            = "/subscriptions/.../myAppPlan" -> (known after apply) # forces replacement
      - app_settings                   = {
          - "WEBSITE_RUN_FROM_PACKAGE" = "https://mystorageaccount.blob.core.windows.net/..."
        } -> null
        client_affinity_enabled        = false
      ~ default_hostname               = "myapp.azurewebsites.net" -> (known after apply)
        enable_builtin_logging         = false
        enabled                        = true
        https_only                     = false
      ~ id                             = "/subscriptions/.../myApp" -> (known after apply)
      ~ kind                           = "functionapp,linux" -> (known after apply)
        location                       = "westeurope"
        name                           = "myApp"
...

This is a really annoying behavior. Do I miss something or is this a bug?

[ghost]

Have you tried setting the kind to: FunctionApp

It looks like that is the cause of the replacement and is a valid kind.

[bufanda]

Hm, with FunctionApp it seems to work, but what I found out was also that if I change the Plan to Basic B1 for example the Linux kind works perfectly fine.
Additional it seems like the Linux Dynamic Plan is still preview. Might it be that this doesn't work because of it's preview state?
I got now 2 concerns

1. How do I know that FunctionApp is Linux and not Windows. Is it some where documented, that the Kind FunctionApp is always Linux?
2. How is it possible that Microsoft can overwrite terraform and terraform doesn't give feedback like a warning? Maybe kind incompatible with sku? Just wondering.

[ghost]

I believe that kind "FunctionApp" on the plan will accept both Windows & Linux and that is then specified by the Function App itself. I could be wrong on this however as I haven't dived in to the code to check.

I also think SKU in Terraform validations just checks that it is a valid SKU for the resource type rather than the type and kind. There is a couple of instances where we have had issues around SKU being incorrect and defaulting.

[oksankaa]

Similar issue: #4116, but about function.

[imduchy]

#6931 also seems to be related

[mikemowgli]

tried this morning with release 2.21.0 and could make it work with kind = "FunctionApp" and reserved = true (and no need to ignore lifecycle changes. These settings actually produce a Linux capable App Service Plan. So for me 2.21.0 fixed this issue, along with #7960 .
Can you guys confirm you have the same experience?

[njuCZ]

Hi All, I have fired another PR to change the doc of reserved, and add check. It seems the backend service will change the kind to functionapp if sku tier is dynamic. will change kind to elastic if sku tier is ElasticPremium. I added check in terraform to avoid such config.

FunctionApp could use windows or linux platform, which is controlled by reserved field, somewhat wield. Hopes this could fix all of your question.

[juanjojulian]

I still have this problem

Terraform v0.13.5
+ provider registry.terraform.io/-/azurerm v2.39.0
+ provider registry.terraform.io/-/random v3.0.0
+ provider registry.terraform.io/hashicorp/azurerm v2.39.0
+ provider registry.terraform.io/hashicorp/random v3.0.0

resource "azurerm_app_service_plan" "My-p-appServicePlan-01" {
  name                = "My-p-appServicePlan-01"
  location            = azurerm_resource_group.functionApp.location
  resource_group_name = azurerm_resource_group.functionApp.name
  kind                = "FunctionApp"
  reserved            = true
  sku {
    tier = "PremiumV2"
    size = "P1v2"
  }
}

Each time Terraform runs it tries to change

  # azurerm_app_service_plan.My-p-appServicePlan-01 must be replaced
-/+ resource "azurerm_app_service_plan" "My-p-appServicePlan-01" {
      ~ id                           = "/subscriptions/4****************/resourceGroups/My-p-functionApp-rg/providers/Microsoft.Web/serverfarms/My-p-appServicePlan-01" -> (known after apply)
      - is_xenon                     = false -> null
      ~ kind                         = "linux" -> "FunctionApp" # forces replacement
        location                     = "westeurope"
      ~ maximum_elastic_worker_count = 1 -> (known after apply)
      ~ maximum_number_of_workers    = 30 -> (known after apply)
        name                         = "My-p-appServicePlan-01"
      - per_site_scaling             = false -> null
        reserved                     = true
        resource_group_name          = "My-p-functionApp-rg"
      - tags                         = {} -> null

      ~ sku {
          ~ capacity = 1 -> (known after apply)
            size     = "P1v2"
            tier     = "PremiumV2"
        }
    }

only solution is to set:

    lifecycle {
    ignore_changes = [
      kind,
    ]
  }```

[vikas027]

To all who stumbles on this issue, azurerm_app_service_plan is deprecated now in favour of azurerm_service_plan. I don't have this issue anymore.

terraform {
  required_version = "1.5"

  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "3.60.0"
    }
  }
}

resource "azurerm_service_plan" "sp" {
  name                     = module.naming.app_service_plan.name
  location                 = azurerm_resource_group.rg.location
  resource_group_name      = azurerm_resource_group.rg.name
  os_type                  = "Linux"
  sku_name                 = "S1"
  worker_count             = 1
  zone_balancing_enabled   = false
  per_site_scaling_enabled = false
}

[katbyte]

Hey all i am going to close this because as @vikas027 has mentioned the azurerm_app_service_plan has been superceeded by the azurerm_service_plan which does not appear to have this issue.

If this is still an issue with v3.x of the provider and the new resource for you please do let us know by opening a new issue, thanks!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.