[azurerm_windows_function_app] Remove of WEBSITE_NODE_DEFAULT_VERSION and FUNCTIONS_WORKER_RUNTIME app setting without mention in plan output

[StefanSchoof]

Is there an existing issue for this?

• I have searched the existing issues

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

1.1.9

AzureRM Provider Version

3.5.0

Affected Resource(s)/Data Source(s)

azurerm_windows_function_app

Terraform Configuration Files

provider "azurerm" {
  features {}
}

data "azurerm_storage_account" "example" {
  name                = "nodeversiontesta275"
  resource_group_name = "node_version_test"
}

data "azurerm_service_plan" "example" {
  name                = "ASP-nodeversiontest-9734"
  resource_group_name = "node_version_test"
}

resource "azurerm_windows_function_app" "example" {
  builtin_logging_enabled = false
  client_certificate_mode = "Required"
  name                    = "nodeversiontest"
  resource_group_name     = "node_version_test"
  location                = "West Europe"

  storage_account_name       = data.azurerm_storage_account.example.name
  service_plan_id            = data.azurerm_service_plan.example.id
  storage_account_access_key = data.azurerm_storage_account.example.primary_access_key

  lifecycle {
    ignore_changes = [
      tags
    ]
  }

  site_config {
    ftps_state              = "AllAllowed"
    scm_minimum_tls_version = "1.0"
  }
}

Debug Output/Panic Output

https://gist.github.com/StefanSchoof/6e9fe1ec75c51cf86d69c84d3419c479

Expected Behaviour

terraform shows the change of the WEBSITE_NODE_DEFAULT_VERSION and FUNCTIONS_WORKER_RUNTIME of the app settings in the plan output

Actual Behaviour

terraform shows no change to WEBSITE_NODE_DEFAULT_VERSION and FUNCTIONS_WORKER_RUNTIME

but removes them.
before

after

(the right fix is adding a

  application_stack {
      node_version = "~14"
  }

)

But I think terraform should never change anthing that is not visable in the plan.

Steps to Reproduce

1. Create Azure Function in the Portal with Node 14
2. Import terraform import azurerm_windows_function_app.example /subscriptions/dd47ff80-9de3-45ec-a16d-75f3599d9f8b/resourcegroups/node_version_test/providers/Microsoft.Web/sites/nodeversiontest
3. terraform apply

Important Factoids

No response

References

#16196
#16650

[lonegunmanb]

Hi @StefanSchoof , I'd like to explain why this issue happened.

In the resource code, when provider read the function's app_settings, it seems like the code will ignore WEBSITE_NODE_DEFAULT_VERSION in the app_settings. After import, the app_settings in the state is empty, if you execute apply then it will override the app_settings with empty map.

@jackofallops How can we fix this issue? I'd like to try a fix but I don't know why we've ignored WEBSITE_NODE_DEFAULT_VERSION so I think it's better not fix it until I've got further instruction from you. Any advice will be appreciated.

[jackofallops]

Hi @StefanSchoof - Are you modifying the app outside of Terraform here? The service default for that property is ~12, which unfortunately the service also omits from the response if it has not been explicitly sent in the create request, which is why the provider has to filter it out. If you're updating the App externally, such as via Azure DevOps, Terraform will attempt to restore the resource to its defined configuration, including any defaults / properties not set. If you need to control those settings outside of Terraform, you can either match up the Terraform configuration values to those that are set by your external process, or you can make use of ignore_changes for properties you don't want Terraform to manage. (Docs on that here)

Does that help?

[StefanSchoof]

Thanks @jackofallops for the answer. We were in the process of importing existing resources to manage they in the future via terraform. Removing this setting without mention in the plan brought down our webapp. We did not understand the cause of this because terraform mention no change about the WEBSITE_NODE_DEFAULT_VERSION.

And then I tried to reproduce the issue. I created a new web app with node 14 in the portal and run then an import. After the first apply the WEBSITE_NODE_DEFAULT_VERSION was gone.

The problem for me is fixed and since I now know I should always set application_stack I will not run in this issue again.

But I think this behavior is danger for everyone, who tries to import an existing web app in terraform.

[lonegunmanb]

Hi @jackofallops , thanks for your reply. Since the WEBSITE_NODE_DEFAULT_VERSION has been filtered out in the read function, I found that we have no way to store it in the Terraform state file if we use terraform import.

My reproduce code:

provider "azurerm" {
  features {
    resource_group {
      prevent_deletion_if_contains_resources = false
    }
  }
}

resource "azurerm_resource_group" "example" {
  name     = "zjhe-f16681"
  location = "West Europe"
}

resource "azurerm_storage_account" "example" {
  name                     = "zjhef16681"
  resource_group_name      = azurerm_resource_group.example.name
  location                 = azurerm_resource_group.example.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

resource "azurerm_service_plan" "example" {
  name                = "zjhe-f16681"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_resource_group.example.location
  os_type             = "Windows"
  sku_name            = "Y1"
}

resource "azurerm_windows_function_app" "example" {
  name                = "zjhef16681"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_resource_group.example.location

  storage_account_name = azurerm_storage_account.example.name
  service_plan_id      = azurerm_service_plan.example.id

  site_config {}

  app_settings = {
    WEBSITE_NODE_DEFAULT_VERSION = "~14"
    WEBSITE_CONTENTAZUREFILECONNECTIONSTRING = azurerm_storage_account.example.primary_connection_string
  }
}

output "resgp_id" {
  value = azurerm_resource_group.example.id
}

output "storage_account_id" {
  value = azurerm_storage_account.example.id
}

output "svc_plan_id" {
  value = azurerm_service_plan.example.id
}

output "func_id" {
  value = azurerm_windows_function_app.example.id
}

I've applied the code, then I copied the tf code to a new folder, import all resources one by one. Then I tried to export azurerm_windows_function_app.example.app_settings in Terraform console, the result is tomap({}).

If we use Terraform to manage the function app, it will delete WEBSITE_NODE_DEFAULT_VERSION eventually, no matter how we set it in our code or externally. Is this behavior by design? Thanks.

[jackofallops]

Hi @lonegunmanb - The intended way to manage that setting is via the app_stack block, not the app_setting. WEBSITE_NODE_DEFAULT_VERSION value directly, so this is working as intended, and differs to the deprecated resource. This design decision was taken as the app_settings map is a much-overloaded object in the service, used for System and User settings, several of which have multiple routes to update values, and in some cases have additional knock-on effects that can change other configuration items elsewhere in the resource.

The gap here is one of documentation, specifically calling out explicitly that the app_stack block should be used for these values, so the provider can manage them correctly, and in the correct order.

@StefanSchoof - Thanks for the understanding, and apologies for the confusion. I'll take a look at adding a section to the docs on the import process to help clarify this for other users that may hit the same issue! I'll leave this issue open for now, and link the docs PR back to it when we open that.

Thanks again!

[StefanSchoof]

I think having a application_stack in the example will also help l. Having a function without a application_stack sounds for me as that is some edge case and not the default.

[lonegunmanb]

@jackofallops I'd like to help on this issue, would you please give me some instructions on how to improve the document so I can try a pr? Thanks!

[re-sounding]

I have set application_stack.node_version to ~16 in my tf file (which was created by importing an existing azure function app config). Every so often, WEBSITE_NODE_DEFAULT_VERSION in the azure portal is automatically removed causing my service to fail. Is this expected? What am I doing wrong?

[dribblor]

Similar thing happens on azurerm_windows_web_app also, not just the function app, and the documentation for this resource is missing a lot of what's in the function app docs.