`virtual_network_subnet_id` is always reset when connecting to virtual network using `azurerm_app_service_virtual_network_swift_connection`

[RaulBurian]

Is there an existing issue for this?

• [X] I have searched the existing issues

Community Note

• Please vote on this issue by adding a :thumbsup: 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.6

AzureRM Provider Version

3.17

Affected Resource(s)/Data Source(s)

azurerm_windows_web_app, azurerm_windows_function_app (maybe also applies to the linux versions)

Terraform Configuration Files

resource "azurerm_windows_function_app" "azure_function" {
  name                        = "func"
  location                    = var.location
  resource_group_name         = var.resource_group_name
  service_plan_id             = azurerm_service_plan.functions.id
  storage_account_name        = azurerm_storage_account.functions.name
  storage_account_access_key  = azurerm_storage_account.functions.primary_access_key
  functions_extension_version = "~4"

  identity {
    type = "SystemAssigned"
  }

  site_config {
    always_on     = true

    application_stack {
      dotnet_version              = 6
      use_dotnet_isolated_runtime = true
    }
  }
}

resource "azurerm_app_service_virtual_network_swift_connection" "func_conn" {
  app_service_id = azurerm_windows_function_app.functions.id
  subnet_id      = azurerm_subnet.functions_subnet.id
}

Debug Output/Panic Output

# azurerm_windows_function_app.azure_function will be updated in-place
  ~ resource "azurerm_windows_function_app" "azure_function" {
        id                                = "{funcId}"
        name                              = "{funcName}"
      - virtual_network_subnet_id         = "/subscriptions/{subId}/resourceGroups/{rgName}/providers/Microsoft.Network/virtualNetworks/{vNetName}/subnets/{subnetName}" -> null
        # (25 unchanged attributes hidden)

        # (3 unchanged blocks hidden)
    }

Expected Behaviour

In the documentation https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/windows_function_app#virtual_network_subnet_id, it says that the attribute virtual_network_subnet_id is optional and using both it and azurerm_app_service_virtual_network_swift_connection is not possible simulatenously.

We expected that by using azurerm_app_service_virtual_network_swift_connection terraform would recognize that the vNet connection is being done through it and wouldn't try to always modify the value of the virtual_network_subnet_id even if we did not use it.

Actual Behaviour

Whenever we run our terraform, if the vNet association does not exist, it gets created accordingly to our azurerm_app_service_virtual_network_swift_connection resource.

However, whenever we want to run terraform again after the association is created, terraform will see the attribute virtual_network_subnet_id to be changed and it will try to set it back to null even if we used the swift connection link method.

This leads to the deletion of the vNet integration of our azure function / web app.

We would assume that if we are using the swift connection resource, terraform would ignore the attribute virtual_network_subnet_id, since it is documented that setting both is not possible.

Steps to Reproduce

No response

Important Factoids

No response

References

No response

[DSollickOnyx]

Just wanted to confirm that this is an issue for the azurerm_linux_web_app resource as well.

I think this is probably obvious to most users, but for the moment the workaround would be to add an ignore_changes block.

lifecycle { ignore_changes = [virtual_network_subnet_id] }

[TheGreatWardino]

Also confirming that this issue is present in the azurerm_linux_web_app resource.

Really glad I finally found this being posted somewhere.

FWIW, I also updated to provider 3.20.0 and the issue is still present.

Will try implementing that workaround @DSollickOnyx - thanks!

[IronMania]

I found a similar issue with an existing MR. https://github.com/hashicorp/terraform-provider-azurerm/issues/18288

[skillbuilderzone]

Same issue with 'azurerm_logic_app_standard' Using version = "3.24.0"

[cvallesi-kainos]

Not sure this is the exact same issue but surely is related: https://github.com/hashicorp/terraform-provider-azurerm/issues/18701

[xiaxyi]

Thanks guys for the discussion, the detailed notes were added in this pr:https://github.com/hashicorp/terraform-provider-azurerm/pull/18738

[vanmash]

Looks like https://github.com/hashicorp/terraform-provider-azurerm/issues/17930#issuecomment-1216719591 is the "solution" :/

[thomasbeauvais]

This is terrible! Do we have a fix that is not a hack?

lifecycle { ignore_changes = [virtual_network_subnet_id] }

This is a hack and not a solution. It sets the virtual_network_subnet_id to null every time for NO REASON!

Please, please fix this. I will give you a hug!

[DSollickOnyx]

100% agreed with @thomasbeauvais -- it's one thing when Azure has an underlying bug that cannot be addressed, it's another when this seems to all observers to be a provider issue. My suggestion was simply a workaround as I don't have the deeper TF/Go knowledge to fix it otherwise and that would at least eliminate it from being an all-the-time issue, but it by no means should be permanent.

[IronMania]

a workaround is to not use the swift connection. use the virtual_network_subnet_id instead

[orjan]

a workaround is to not use the swift connection. use the virtual_network_subnet_id instead

Note: if you’re changing from swift you’ll loose the network connection for a while. When you re-run terraform it’ll re-create the connection.

[cvallesi-kainos]

Can confirm using virtual_network_subnet_id resolve the issue. Also will generate downtime, couldn't find a way around that. The average has been 30 minutes which is A LOT.

[orjan]

disclaimer: I have not tested this, so it's just an idea.

I can imagine that it would be possible to add virtual_network_subnet_id and mark the swift connection as deleted e.g. removed from the terraform state?

[mimuruth-msft]

The AzureRM Terraform provider provides regional virtual network integration via the standalone resource app_service_virtual_network_swift_connection and in-line within this resource using the virtual_network_subnet_id property. You cannot use both methods simultaneously. If the virtual network is set via the resource app_service_virtual_network_swift_connection then ignore_changes should be used in the web app configuration.

[aaronswainonset]

I've just updated all my TF code from AzureRM 2.99.0 to 3.51.0, can confirm this defect still exists.

As per the documentation, for azurerm_linux_web_app resources I'm using azurerm_app_service_virtual_network_swift_connection and NOT virtual_network_subnet_id.

This issue needs two actions:

1. Update the documentation to make it clear that azurerm_app_service_virtual_network_swift_connection doesn't work as expected.
2. Fix the bug.

[brandonavant]

I can confirm that this is still happening in v3.57.0.

[xiaxyi]

@brandonavant , have you tried using ignore change life cycle?

[brandonavant]

@brandonavant , have you tried using ignore change life cycle?

Thanks for the reply. I ended up removing the azurerm_app_service_virtual_network_swift_connection and instead explicitly indicating the virtual_network_subnet_id. This worked but I did experience about 30-45 minutes of network downtime, as others have mentioned.

I personally think this is the better option for now. I'm not a fan of the lifecycle { ignore_changes = [virtual_network_subnet_id] } option as it feels hacky to me...

[AkodoShado]

In v3.65.0 is still there. I spend 2h to find what's goining on. What are good practices in this area? Is it better to use dedicated terraform resources or only use them when there is no other way? I assume there is no simple answer and it depends :)

[vanmash]

in v3.74.0. still there

[ygandepalli-seagen]

did someone find solution for this issue, I tried life cycle ignore and depends on but the issue remains same.

[brandonavant]

did someone find solution for this issue, I tried life cycle ignore and depends on but the issue remains same.

Have you tried switching to virtual_network_subnet_id? IMHO, this is the cleanest solution.

[segoranov]

Confirming that using virtual_network_subnet_id resolves the issue for linux function app.

[iqbal-kiratech]

Confirming that using virtual_network_subnet_id resolves the issue for linux function app.

can you give example of the terraform using that virtual_network_subnet_id and also if using this will it cause downtime on the function app? as mention by @brandonavant

@brandonavant , have you tried using ignore change life cycle?

Thanks for the reply. I ended up removing the azurerm_app_service_virtual_network_swift_connection and instead explicitly indicating the virtual_network_subnet_id. This worked but I did experience about 30-45 minutes of network downtime, as others have mentioned.

[drdamour]

has anyone figured out why using virtual_network_subnet_id causes downtime. i saw in https://github.com/hashicorp/terraform-provider-azurerm/issues/15213#issuecomment-1131348394 that they use different azure services to do the allocation...but is the new one that backs virtual_network_subnet_id supposed to be so bad with downtime?

[michasacuer]

Still the same issue with provider 3.95 and 3.96. Guys, its opened for two years, dont you use virtual network in your company? It looks for me as top priority to fix that bug

[chintavasisht]

@tombuildsstuff Bringing this to your attention, since this has been open for a long while now (starting from 3.24 when it was introduced to latest). The ignore lifecycle is not a good solution for a lot of people who use it along with the swift_connection resource. In my particular case I need the azurerm_logic_app_standard resource to be backwards compatible with AzureRm 2.x as well, so I can't just add a lifecycle block for the virtual_network_subnet_id

[tombuildsstuff]

👋

Taking a look through here this doesn't appear to be a bug in the Provider bug an expected behaviour given this field can be configured both in-line and using the separate resource

As noted in the documentation when using the separate azurerm_app_service_virtual_network_swift_connection resource you must use ignore_changes on the virtual_network_subnet_id field - else Terraform will plan to remove it since the config doesn't match what's applied in Azure.

Because this field is configurable in both places, without the ignore_changes we're unable to determine if this value's been added outside of Terraform (and so it should be planned to be removed), or if it's intentionally not set in that resource due to using the split-out resource and so should be ignored - as such unfortunately this isn't a bug (more details about ignore_changes can be found in the Terraform Core documentation).

Since this'll be fixed by updating your Terraform Configuration to use ignore_changes, as is described here - I'm going to close this issue for the moment - but if using ignore_changes doesn't fix this issue then let us know and we can take another look.

Thanks!

[vanmash]

The documentation says

In some rare cases, settings of a remote object are modified by processes outside of Terraform, which Terraform would then attempt to "fix" on the next run

For what reason adding VNET integration is a "rare" case?

The requirement to use ignore_changes looks like a design flaw to me.

[michasacuer]

Indeed, for me vnet integration is default way to got

On Sat, Apr 6, 2024, 12:29 Maciek @.***> wrote:

The documentation https://developer.hashicorp.com/terraform/language/meta-arguments/lifecycle says

In some rare cases, settings of a remote object are modified by processes outside of Terraform, which Terraform would then attempt to "fix" on the next run

For what reason adding VNET integration is a "rare" case?

The requirement to use ignore_changes looks like a design flaw to me.

— Reply to this email directly, view it on GitHub https://github.com/hashicorp/terraform-provider-azurerm/issues/17930#issuecomment-2041042288, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI43PAZ6AQAMWVC3ZZUMM6LY37FAFAVCNFSM557VKNX2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBUGEYDIMRSHA4A . You are receiving this because you commented.Message ID: @.***>