[fixed in 1.42 back in 2.0] azurerm_subnet delegation: If "Actions" is empty Terraform modifies the subnet on each "apply"

[juanjojulian]

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 (and AzureRM Provider) Version

juanjo@Dune spoke-cdt-lab-dev-westeurope$ terraform version
Terraform v0.12.21
+ provider.azurerm v2.0.0

Affected Resource(s)

• azurerm_subnet

Terraform Configuration Files

resource "azurerm_subnet" "example" {
  name                 = "testsubnet"
  resource_group_name  = "${azurerm_resource_group.example.name}"
  virtual_network_name = "${azurerm_virtual_network.example.name}"
  address_prefix       = "10.0.1.0/24"

  delegation {
    name = "acctestdelegation"

    service_delegation {
      name    = "Microsoft.ContainerInstance/containerGroups"
    }
  }
}

Expected Behavior

Once the subnet is deployed no more changes should be attempted.

Actual Behavior

Terraform tries to remove the default "actions" each time you apply or plan:

      ~ delegation {
            name = "westeurope-sql-mi-dev-delegation"

          ~ service_delegation {
              ~ actions = [
                  - "Microsoft.Network/virtualNetworks/subnets/join/action",
                  - "Microsoft.Network/virtualNetworks/subnets/prepareNetworkPolicies/action",
                  - "Microsoft.Network/virtualNetworks/subnets/unprepareNetworkPolicies/action",
                ]
                name    = "Microsoft.Sql/managedInstances"
            }
        }

Steps to Reproduce

Create a subnet with delegation and no actions, remember that as per Terraform docs "actions" is optional.

Important Factoids

This bug was happening before azurerm v1.42.0 and was fixed in that version, it came back from the future? original bug report was #5476 fixed in #5484

[tombuildsstuff]

hi @juanjojulian

Thanks for opening this issue.

Whilst PR #5484 made this field Computed, upon further investigation this field supports specifying values other than the defaults provided by Azure (since these can change over time) and thus we've opted to make this field non-computed so users can specify the values they expect. As such the change to make this field computed got reverted in 2.0 so that this now shows as a diff (since this affects network traffic/security policies).

Instead it's possible to remove this diff either by specifying the appropriate values for the actions field based on the service delegation being used - or by using the ignore_changes field to ignore the changes for this field if you're interested in using Azure's defaults. Whilst I appreciate it's unfortunate the behaviour of this field has changed, this is done to better match the behaviour of the Azure API.

Since this should be fixed by updating the Terraform Configuration (either to specify the values for this field, or by using ignore_changes) I'm going to close this issue for the moment, but please let us know if those suggestions don't work for you and we'll take another look.

Thanks!

[juanjojulian]

Hi @tombuildsstuff

Thanks for the explanation.

While its true that the Azure API allows to configure the actions, the standard behaviour in Azure Portal and CLI when configuring subnet delegations is to assign a default set of actions, in fact I don't see an easy way to modify the actions neither from the Portal nor the CLI. Is it possible to configure azurerm provider to configure the default set of actions in case none is provided like in the Portal/CLI? it will make users life easier.

Problem with making use of:

  lifecycle {
    ignore_changes = [
      delegation,
    ]
  }

It will configure delegations in first subnet deployment but will not remove them if you change the code or re-apply them if someone makes a manual change.

[juanjojulian]

My approach to mitigate this problem is the following (but it really makes my life more complicated as I have to maintain one more thing in the code). I created a new variable in my network module with all the possible actions mapped to their respective delegations:

variable "subnet_delegations_actions" {
  type = map(list(string))
  default = {
    "Microsoft.Web/serverFarms"                       = ["Microsoft.Network/virtualNetworks/subnets/action"]
    "Microsoft.ContainerInstance/containerGroups"     = ["Microsoft.Network/virtualNetworks/subnets/action"]
    "Microsoft.Netapp/volumes"                        = ["Microsoft.Network/networkinterfaces/*", "Microsoft.Network/virtualNetworks/subnets/join/action"]
    "Microsoft.HardwareSecurityModules/dedicatedHSMs" = ["Microsoft.Network/networkinterfaces/*", "Microsoft.Network/virtualNetworks/subnets/join/action"]
    "Microsoft.ServiceFabricMesh/networks"            = ["Microsoft.Network/virtualNetworks/subnets/action"]
    "Microsoft.Logic/integrationServiceEnvironments"  = ["Microsoft.Network/virtualNetworks/subnets/action"]
    "Microsoft.Batch/batchAccounts"                   = ["Microsoft.Network/virtualNetworks/subnets/action"]
    "Microsoft.Sql/managedInstances"                  = ["Microsoft.Network/virtualNetworks/subnets/join/action", "Microsoft.Network/virtualNetworks/subnets/prepareNetworkPolicies/action", "Microsoft.Network/virtualNetworks/subnets/unprepareNetworkPolicies/action"]
    "Microsoft.Web/hostingEnvironments"               = ["Microsoft.Network/virtualNetworks/subnets/action"]
    "Microsoft.BareMetal/CrayServers"                 = ["Microsoft.Network/networkinterfaces/*", "Microsoft.Network/virtualNetworks/subnets/join/action"]
    "Microsoft.Databricks/workspaces"                 = ["Microsoft.Network/virtualNetworks/subnets/join/action", "Microsoft.Network/virtualNetworks/subnets/prepareNetworkPolicies/action", "Microsoft.Network/virtualNetworks/subnets/unprepareNetworkPolicies/action"]
    "Microsoft.BareMetal/AzureVMware"                 = ["Microsoft.Network/networkinterfaces/*", "Microsoft.Network/virtualNetworks/subnets/join/action"]
    "Microsoft.StreamAnalytics/streamingJobs"         = ["Microsoft.Network/virtualNetworks/subnets/join/action"]
    "Microsoft.DBforPostgreSQL/serversv2"             = ["Microsoft.Network/virtualNetworks/subnets/join/action"]
    "Microsoft.AzureCosmosDB/clusters"                = ["Microsoft.Network/virtualNetworks/subnets/join/action"]
  }
}

And this is how I make use of it, if a delegation is created then the "actions" are populated with a list with its corresponding actions.

  dynamic "delegation" {
    for_each = contains(keys(var.subnet_delegations), each.key) ? [1] : []
    content { 
      name = "${each.key}-delegation"
      service_delegation {
        name    = var.subnet_delegations[each.key]
        actions = var.subnet_delegations_actions[var.subnet_delegations[each.key]]
      }
    }
  }

But I'm not very happy having to maintain this variable updated with Azure constant changes..

[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 👉 [email protected]. Thanks!