azurem_windows_app_slot service_plan_id is reset when it has not changed

[daveneeley]

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

AzureRM Provider Version

3.41.0

Affected Resource(s)/Data Source(s)

azurem_windows_app_slot

Terraform Configuration Files

terraform {
  required_version = ">= 1.4.0"
  required_providers {
    azurerm = {
      // 3.41.0 breaks azurerm_windows_app_slot if `service_plan_id` is included but unchanged
      source  = "hashicorp/azurerm"
      version = "3.41.0"
    }
  }
}

provider "azurerm" {
  features {}
}
data "azurerm_resource_group" "tf" {
  name = "rg"
}

resource "random_string" "tf" {
  length  = 20
  special = false
  upper   = false
}

resource "azurerm_service_plan" "tf" {
  name                = random_string.tf.result
  resource_group_name = data.azurerm_resource_group.tf.name
  location            = data.azurerm_resource_group.tf.location
  os_type             = "Windows"
  sku_name            = "P1v2"
}

resource "azurerm_windows_web_app" "tf" {
  name                = random_string.tf.result
  location            = data.azurerm_resource_group.tf.location
  resource_group_name = data.azurerm_resource_group.tf.name
  service_plan_id     = azurerm_service_plan.tf.id
  app_settings = {}

  site_config {}
}

resource "azurerm_windows_web_app_slot" "tf" {
  name            = "staging"
  app_service_id  = azurerm_windows_web_app.tf.id
  service_plan_id = azurerm_service_plan.tf.id
  app_settings = {}

  site_config {}

}

Debug Output/Panic Output

From second apply:

tf apply -auto-approve
random_string.tf: Refreshing state... [id=4i7si1f8xenfk76hmxfo]
data.azurerm_resource_group.tf: Reading...
data.azurerm_resource_group.tf: Read complete after 0s [id=/subscriptions/redacted/resourceGroups/redacted]
azurerm_service_plan.tf: Refreshing state... [id=/subscriptions/redacted/resourceGroups/redacted/providers/Microsoft.Web/serverfarms/4i7si1f8xenfk76hmxfo]
azurerm_windows_web_app.tf: Refreshing state... [id=/subscriptions/redacted/resourceGroups/redacted/providers/Microsoft.Web/sites/4i7si1f8xenfk76hmxfo]
azurerm_windows_web_app_slot.tf: Refreshing state... [id=/subscriptions/redacted/resourceGroups/redacted/providers/Microsoft.Web/sites/4i7si1f8xenfk76hmxfo/slots/staging]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # azurerm_windows_web_app_slot.tf will be updated in-place
  ~ resource "azurerm_windows_web_app_slot" "tf" {
        id                                = "/subscriptions/redacted/resourceGroups/redacted/providers/Microsoft.Web/sites/4i7si1f8xenfk76hmxfo/slots/staging"
        name                              = "staging"
      + service_plan_id                   = "/subscriptions/redacted/resourceGroups/redacted/providers/Microsoft.Web/serverfarms/4i7si1f8xenfk76hmxfo"
        tags                              = {}
        # (16 unchanged attributes hidden)

        # (2 unchanged blocks hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.
azurerm_windows_web_app_slot.tf: Modifying... [id=/subscriptions/redacted/resourceGroups/redacted/providers/Microsoft.Web/sites/4i7si1f8xenfk76hmxfo/slots/staging]
2023-03-19T10:07:03.832-0600 [ERROR] provider.terraform-provider-azurerm_v3.41.0_x5: Response contains error diagnostic: @module=sdk.proto diagnostic_severity=ERROR diagnostic_summary="parsing Azure ID: parse "": empty url" @caller=github.com/hashicorp/terraform-plugin-go@v0.14.3/tfprotov5/internal/diag/diagnostics.go:55 diagnostic_detail="parsing Azure ID: parse "": empty url" tf_proto_version=5.3 tf_provider_addr=provider tf_req_id=d7291ef9-b0ce-a700-ca4b-7eaebfd94d17 tf_resource_type=azurerm_windows_web_app_slot tf_rpc=ApplyResourceChange timestamp=2023-03-19T10:07:03.832-0600
2023-03-19T10:07:03.841-0600 [ERROR] vertex "azurerm_windows_web_app_slot.tf" error: parsing Azure ID: parse "": empty url
╷
│ Error: parsing Azure ID: parse "": empty url
│ 
│   with azurerm_windows_web_app_slot.tf,
│   on main.tf line 43, in resource "azurerm_windows_web_app_slot" "tf":
│   43: resource "azurerm_windows_web_app_slot" "tf" {
│ 
│ parsing Azure ID: parse "": empty url

Expected Behaviour

If service_plan_id is specified and has not changed, it should not be marked as new.

Actual Behaviour

On the second apply, the error Error: parsing Azure ID: parse "": empty url is returned. The execution plan states that service_plan_id will be added (as if it was not set before).

The error message is not helpful, nor is the debug output. Neither says service_plan_id is empty, only the plan suggests that.

Steps to Reproduce

• terraform apply
• terraform apply (again)
• note error parsing Azure ID: parse "": empty url

Important Factoids

No response

References

#19459 / v 3.41.0 introduces windows_app_service_slot.service_plan_id.

In v3.40.0, service_plan_id cannot be specified on a web app slot; in v3.41.0 it is optional but allowed. If it's present, it is not checked against the previous value.

[xiaxyi]

Thanks @daveneeley for raising this issue.

Can I confirm with you about the exact behavior? The service plan id that's specified in the TF config is not the same to the existing one that's associated to this app service slot and the specified one is not being respected by provider?

[daveneeley]

The service plan id was unchanged. It was the same as when it was created.

[daveneeley]

Perhaps that means the service plan id was just not saved to the slot object at all.

[xiaxyi]

Thanks for the clarification, if this is the case, then you will get the diff in every plan? Let me try reproducing from my side.

[ohbriansung]

I have the same issue with azurerm_linux_function_app_slot resource. I am making this comment since the original post was for another resource. The service_plan_id was not changed and terraform apply tried to add it. Got the same error message as the one from the OP.

See failure:

Terraform will perform the following actions:

  # azurerm_function_app_active_slot.canary_app_active_slot will be created
  + resource "azurerm_function_app_active_slot" "canary_app_active_slot" {
      + id                       = (known after apply)
      + last_successful_swap     = (known after apply)
      + overwrite_network_config = true
      + slot_id                  = "/subscriptions/***/resourceGroups/qaas-dev/providers/Microsoft.Web/sites/canary-app-dev/slots/secondary-slot"
    }

  # azurerm_linux_function_app_slot.canary_app_slot will be updated in-place
  ~ resource "azurerm_linux_function_app_slot" "canary_app_slot" {
      ~ app_settings                      = {
          - "WORKSPACE"                                               = "dev"
        } -> (known after apply)
        id                                = "/subscriptions/***/resourceGroups/qaas-dev/providers/Microsoft.Web/sites/canary-app-dev/slots/secondary-slot"
        name                              = "secondary-slot"
      + service_plan_id                   = "/subscriptions/***/resourceGroups/qaas-multi-az-dev/providers/Microsoft.Web/serverfarms/linux-service-plan-dev-2"
        tags                              = {}
        # (20 unchanged attributes hidden)

        # (2 unchanged blocks hidden)
    }

Plan: 1 to add, 1 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

azurerm_linux_function_app_slot.canary_app_slot: Modifying... [id=/subscriptions/***/resourceGroups/qaas-dev/providers/Microsoft.Web/sites/canary-app-dev/slots/secondary-slot]
╷
│ Error: parsing Azure ID: parse "": empty url
│ 
│   with azurerm_linux_function_app_slot.canary_app_slot,
│   on function.tf line 159, in resource "azurerm_linux_function_app_slot" "canary_app_slot":
│  159: resource "azurerm_linux_function_app_slot" "canary_app_slot" {
│ 
│ parsing Azure ID: parse "": empty url

[ohbriansung]

@daveneeley A quick follow-up on my comment above. If your slot is using the same service_plan_id as your web app, remove the service_plan_id from the azurerm_windows_web_app_slot resource will solve the issue. When not specifying the service_plan_id for the slot, it will default to use the same service plan as your web app. (source)

[daveneeley]

Yes! I eventually arrived at this conclusion.

[jfcroteau]

In my case, I'm trying to change the service plan (cleaning terraform debt from azurerm_app_service_plan to azurerm_service_plan), and get the same error.

module.common.azurerm_windows_web_app_slot.externalprovidersstagingslot: Modifying... [id=xxx/providers/Microsoft.Web/sites/yyy/slots/staging]
╷
│ Error: parsing Azure ID: parse "": empty url
│
│ with module.common.azurerm_windows_web_app_slot.externalprovidersstagingslot,
│ on ../common/webapp.tf line 49, in resource "azurerm_windows_web_app_slot" "externalprovidersstagingslot":
│ 49: resource "azurerm_windows_web_app_slot" "externalprovidersstagingslot" {
│
│ parsing Azure ID: parse "": empty url
╵
So it looks like I need to put it 1 time the service_plan_id explicetly, then remove it.

I'm using azurerm 3.62.1 (latest as of today)

[jbhuguenin]

@daveneeley A quick follow-up on my comment above. If your slot is using the same service_plan_id as your web app, remove the service_plan_id from the azurerm_windows_web_app_slot resource will solve the issue. When not specifying the service_plan_id for the slot, it will default to use the same service plan as your web app. (source)

But when you change service_plan_id of web app, web app slot dos not change service_plan_id

[PatrykIti]

Hello Everyone. I agree with @jbhuguenin. It is ok when you are going to deploy from zero the WebApp and slots for it. But if you want to manage existing environment and have a case to change App Service Plan to another one then the WebApp will be moved to new App Service Plan but slot stays on the old one.
I think that it is terraform issue which it cannot handle properly the 'serivce_plan_id' parameter for web app slots.

It will be best to fix it because it will help moving apps with slots to another service plan.

[xiaxyi]

@PatrykIti May I know how did you swapped the service plan for app service? When I tried to change the service plan for linux web app in azure portal, only the web app will be changed to another service plan but not the app slot. This behavior matches terraform's behaviour, so can you let me know how did you changed the service plan and have you tried to use the api/ azure portal directly?

[xiaxyi]

I think the issue is the service_plan_id won't be saved to state if user doesn't specify it in the config, I will figure out a solution for it and update here

[PatrykIti]

Hello @xiaxyi,

Yes, you are right. It is only moving web app to the other app service plan but not the slots. If you add 'service_plan_id' parameter to resource block for the slots it will trigger the error about "parsing Azure ID: parse "": empty url".
If you try run apply second time then terraform somehow will move slots to the other app service plan and for 1 of them I can see the 'service_plan_id' value in the tfstate.
But if you want change any setting for app service plan (without changing config for the app & slots) then terraform will give you in plan output that 'service_plan_id' needs to be added. So again it will trigger the same error about 'parsing Azure ID: parse "": empty url'.

So it seems that terraform cannot handle this functionality for slots somehow.

How I swapped the 'service_plan_id' for web_app? I have a module and the 'service_plan_id' is as input for the web app module so If I add another 'app service plan' to my configuration and change reference between modules to another service plan then terraform will move my app to other service plan :) but as I mentioned it is only working properly for the app itself.

You can move slots to other app service plan via powershell. Also you may encounter some restriction if you want to move Apps between app service plans with different App Service Environments.

$appSlots = Get-AzResource -Name "<name_prefix_of_the_apps>*/*"
$service_plan_id = "<new_service_plan_id>"

foreach($appslot in $appSlots) {

    Set-AzWebAppSlot -AppServicePlan $service_plan_id -Name $appslot.name.split("/")[0] -ResourceGroupName   $appslot.resourcegroupname -Slot $appslot.name.split("/")[1]
}

[veinito]

Similar or a duplicate of #22763?

I can confirm that the azurerm_windows_web_app_slot resource can be created, but afterwards calling plan or apply will always fail with the message above.

Using azurerm_windows_web_app_slot is not idempotent and finishes with error therefore the bottom line is that we can't use azurerm_windows_web_app_slot at all.

[veinito]

EDIT: added versions info

@xiaxyi
I do everything by the book and even specify the service_plan_id, e.g.:

provider "azurerm" {
  features {}
}

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

resource "azurerm_service_plan" "example" {
  name                = "example-plan"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_resource_group.example.location
  os_type             = "Windows"
  sku_name            = "P1v2"
}

resource "azurerm_windows_web_app" "example" {
  name                = "example-windows-web-app"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_service_plan.example.location
  service_plan_id     = azurerm_service_plan.example.id

  site_config {}
}

resource "azurerm_windows_web_app_slot" "example" {
  name           = "example-slot"
  app_service_id = azurerm_windows_web_app.example.id
  service_plan_id     = azurerm_service_plan.example.id

  site_config {}
}

Very first terraform apply runs fine and creates resources, but the second terraform apply (or plan) without any change, fails with error message.

terraform: 1.5.6
azurerm: 3.71.0

[veinito]

By not providing service_plan_id value at all, the creation, update and all following apply calls finish without that error.

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