azurem provider does not record state of security rule changes correctly

[OliverGoetz]

Terraform Version

Terraform v0.10.4
terraform-provider-azurerm_v0.1.7_x4

Affected Resource(s)

Please list the resources as a list, for example:

• network security groups

Terraform Configuration Files

resource "azurerm_resource_group" "nsg-rule-modification-bug" {
  name     = "nsg-rule-modification-bug"
  location = "East US 2"
}

resource "azurerm_network_security_group" "nsg-rule-modification" {
  name = "nsg-rule-modification"
  location = "${azurerm_resource_group.nsg-rule-modification-bug.location}"
  resource_group_name = "${azurerm_resource_group.nsg-rule-modification-bug.name}"
}

resource "azurerm_network_security_rule" "detached-automated-security-rule" {
  name                        = "automated-security-rule"
  priority                    = 100
  direction                   = "Inbound"
  access                      = "Allow"
  protocol                    = "TCP"
  source_port_range           = "*"
  destination_port_range      = "22"
  source_address_prefix       = "10.0.0.0/16"
  destination_address_prefix  = "*"
  resource_group_name         = "${azurerm_resource_group.nsg-rule-modification-bug.name}"
  network_security_group_name = "${azurerm_network_security_group.nsg-rule-modification.name}"
}

Expected Behavior

terraform.tfstate should contain the correct value ("10.0.0.0/16") of the security rule after the script is applied

Actual Behavior

The source_address_prefix of the security rule in the "primary.attributes" section of the azurerm_network_security_group section contains the wrong value ("10.10.0.0/16") in the terraform.tfstate file, while the source_address_prefix in the azurerm_network_security_rule is correct.

After an additional terraform apply run, both entries show the correct value again.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply
2. Go to https://portal.azure.com and change the Source IP address range of the rule to "10.10.0.0/16"
3. terraform apply
4. Check the terraform.tfstate file (and save it by copying it to another name)
5. terraform apply
6. Check the terraform.tfstate file and diff it with the saved file from step 4

[kpeder]

A similar bug is also apparent in the following environment:

Terraform v0.10.7
Azure RM Provider: 0.3.2 and 0.3.3

We find that if a resource requires modification (i.e. we remove a rule manually from the NSG and run an apply) that terraform does the right thing (replaces the rule). However, subsequent plan output still outlines a change. We can run 'plan', 'apply', and 'plan' and receive the same output in steps 1 and 3, and a successful modification in step 2 is reported by terraform.

The main difference here is that the state never seems to get updated, even after subsequent applies.

Related note, we are using remote state on Azure blob storage, but the behavior is reproducible with a local state file as well. This issue was not present at our previous provider version, v0.1.5 using the same version of terraform (v0.10.7).

Would like to see this prioritized if possible, as it's impacting deployment workflows.

[rbramwell]

Would love to see some movement on this as well.

[JunyiYi]

The Computed fields in azurerm_network_security_group is not getting updated when a azurerm_network_security_rule is changed. @tombuildsstuff @katbyte , this seems to be a design defect because there are both the embedded rule as well as the rule resource.

The solution here is, provide a way to trigger the Read of a resource when another related resource is changed (@tombuildsstuff @katbyte , do we have this mechanism in Terraform now?). Or remove the azurerm_network_security_rule resource.

[carct]

is there any plan to fix this bug that was first reported in 2017 and creates issues while using terraform+trafficManager in a production context ? thanks

[tombuildsstuff]

hey @OliverGoetz @kpeder @rbramwell

Thanks for opening this issue - apologies for the delayed response here!

Taking a look into this unfortunately this appears to be a bug in Terraform Core and as such would need to be fixed there. There's an upstream issue tracking this (hashicorp/terraform#8099) where the Terraform Core team should be able to take a look and make a fix; but once the fix is added that should automatically become available to all providers. Since this isn't something we're able to work around in the Azure Provider directly; for the moment I'm going to close this in favour of the upstream issue hashicorp/terraform#8099 - would you mind subscribing to that issue for updates?

Thanks!

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