64 Bit platform and PowerShell Core Version not set for azurerm_windows_function_app

[kpakur]

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.2.1

AzureRM Provider Version

3.8.0

Affected Resource(s)/Data Source(s)

azurerm_windows_function_app

Terraform Configuration Files

terraform {
  required_version = ">= 1.2.1"
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "3.8.0"
    }
  }
}

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "kgroup" {
  name     = "kkgroup"
  location = "uksouth"
}

resource "azurerm_service_plan" "kplan" {
  name                = "kkplan"
  resource_group_name = azurerm_resource_group.kgroup.name
  location            = azurerm_resource_group.kgroup.location
  os_type             = "Windows"
  sku_name            = "P1v3"
}

resource "azurerm_storage_account" "kstorage" {
  name                            = "kkstorage223105" # must be unique across Azure
  resource_group_name             = azurerm_resource_group.kgroup.name
  location                        = azurerm_resource_group.kgroup.location
  account_tier                    = "Standard"
  account_replication_type        = "LRS"
}

resource "azurerm_windows_function_app" "kfunction" {
  name                        = "kkfunction223105" # must be unique across Azure
  resource_group_name         = azurerm_resource_group.kgroup.name
  location                    = azurerm_resource_group.kgroup.location
  service_plan_id             = azurerm_service_plan.kplan.id
  storage_account_name        = azurerm_storage_account.kstorage.name
  storage_account_access_key  = azurerm_storage_account.kstorage.primary_access_key

  site_config {
    application_stack {
      powershell_core_version = "7.2" # when used use_32_bit_worker=false setting dosn't work
    }

    use_32_bit_worker = false
    always_on         = true
  }
}

Debug Output/Panic Output

No panic

Expected Behaviour

1. 64 Bit platform is configured for the function, because use_32_bit_worker = false when using powershell_core_version = "7" or powershell_core_version = "7.2"
2. PowerShell Core Version is set to expected version 7 or 7.2

Actual Behaviour

1. 32 Bit platform is configured for the function. It looks like the platform is not set at all.
2. PowerShell Core Version is empty

Steps to Reproduce

1. terraform init
2. terraform apply

Important Factoids

No response

References

No response

[kpakur]

The workaround for setting 64 Bit is to use
app_settings = { FUNCTIONS_WORKER_RUNTIME = "powershell" }

instead of
application_stack { powershell_core_version = "7.2" }

but that still keeps the PowerShell Core Version empty

[xiaxyi]

@kpakur The powershell version is not being set correctly, I will submit a pr to fix it.

[bdorplatt]

Has any progress been made with this PR? We are seeing the same thing where the PowerShell Core version is not being populated by configuring the application_stack settings.
This is also occurring with azurerm_windows_web_app and azurerm_windows_web_app_slot and the same issue exists when trying to configure .NET and its version through the application_stack block.

application_stack {
  current_stack  = "dotnet"
  dotnet_version =  "v6.0"
}

Using the above application stack settings results in neither the stack or version fields being populated.

[amira1o-edf]

has there been any update on this bug? We are also experiencing PowerShell Core version setting value is not being acknowledged.

[MattJeanes]

@amira1o-edf my understanding is that this has been fixed as of v3.39.0 of the azurerm provider: #19685

[rcskosir]

Thanks for taking the time to submit this issue. It looks like this has been resolved as of #19685. As such, I am going to mark this issue as closed.

[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.