App Service Plan based Function App has erroneous application settings

[APErebus]

We are experiencing an issue when deploying Azure Function app's via Terraform.

When deploying an Azure Function to an App Service Plan, there are two erroneous application settings being added by default.

They are:

• WEBSITE_CONTENTSHARE
• WEBSITE_CONTENTAZUREFILECONNECTIONSTRING

According to Microsoft Docs, these should only be set on Consumption Plan function apps.

Weirdly, those app settings have been there since the resource was included, but it's now causing major issues in Azure. If those settings are removed (say on a deployment that sets other app settings), it causes the backend function runtime to explode and render the entire function app useless.

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

Terraform v0.11.7

Affected Resource(s)

• azurerm_function_app

Terraform Configuration Files

resource "azurerm_app_service_plan" "app_plan" {
  name                = "${var.name}"
  location            = "${var.location}"
  resource_group_name = "${var.resource_group_name}"
  tags                = "${var.tags}"

  sku {
    tier = "Standard"
    size = "S2"
  }
}

resource "azurerm_function_app" "function_apps" {
  name                      = "${var.name}"
  location                  = "${var.location}"
  resource_group_name       = "${var.resource_group_name}"
  app_service_plan_id       = "${azurerm_app_service_plan.app_plan.id}"
  storage_connection_string = "${var.storage_account_connection_string}"
  version                   = "~1"
  tags                      = "${var.tags}"

  site_config {
    always_on = "${var.always_on}"
  }
}

Note: This is not our exact code as I've got it split into modules etc, but the correct properties are set

Expected Behavior

Ideally, these two properties would only be set when creating a consumption app, although I'm not 100% sure that would be checked considering it's the app service plan that dictates if it's consumption...

Actual Behavior

A app service plan function app is created with those two application settings set

Steps to Reproduce

1. terraform apply

[APErebus]

I'm happy give this fix a go, I'm just not sure how to best represent the fix. Ideally, the app service type + sku would dictate if the app settings are set, but I'm not sure if there is a precedent for checking linked resources when building a resource (any examples would be great).

Otherwise, a property on the function_app resource to specify if it's consumption or not seems like the only other way go.

[ranieuwe]

That fix will not work because it blocks you from properly deploying a Consumption plan application where these settings are needed. The easiest way to do this is by only adding these settings if the plan is set to "Dynamic".

Edit: problem is though that you do not have that info in the function app as it is part of the app service plan and you only got the id of that. Only way that would be solvable is by pulling the app service plan first and then building the function app create. @tombuildsstuff or @katbyte thoughts on that?

[APErebus]

Yeah, that fix was strictly a fix for us so we could get through the issues we were having (it was completely stopping testing). I linked it just in case someone else might want it. I intend to update it with the appropriate fix once the issue you identified has been decided.

[APErebus]

@ranieuwe @tombuildsstuff @katbyte Do you know of any existing resources that pull info from a previous resource before it creates itself?

[tombuildsstuff]

@APErebus @ranieuwe I believe we do this for some of the ServiceBus resources, in this case I guess we'd have to look up the containing App Service and assume that it having a SKU of Dynamic was a consumption plan, and omitting the fields that way?

[ranieuwe]

@tombuildsstuff exactly my train of thought. I already have most of the code ready. Will make a PR in the next few days.

[ghost]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks!