azurerm_nginx_deployment- add ForceNew to nested fields

[valyria257]

A bug was found when trying to update a deployment's private IP. The expected behavior is that the deployment should be recreated. However, the actual behavior was that terraform plan showed an in-place update. For example, given the initial applied configuration:

resource "azurerm_nginx_deployment" "dep" {
  name                      = var.dep_name
  resource_group_name       = module.prerequisites.resource_group_name
  sku                       = var.sku
  location                  = var.location
  capacity                  = 20
  automatic_upgrade_channel = "stable"

  frontend_private {
    allocation_method = "Static"
    ip_address        = "10.0.1.100"
    subnet_id         = module.prerequisites.subnet_id
  }

  network_interface {
    subnet_id = module.prerequisites.subnet_id
  }

  tags = var.tags
}

If the following change is then made to the configuration:

- ip_address        = "10.0.1.100"
+ ip_address        = "10.0.1.101"

terraform plan will output the following:

  # azurerm_nginx_deployment.dep will be updated in-place
  ~ resource "azurerm_nginx_deployment" "dep" {
        id                        = "/subscriptions/ee920d60-90f3-4a92-b5e7-bb284c3a6ce2/resourceGroups/valyria-tf-test/providers/Nginx.NginxPlus/nginxDeployments/valyria-tf-dep"
        name                      = "valyria-tf-dep"
        tags                      = {
            "env" = "test"
        }
        # (10 unchanged attributes hidden)

      ~ frontend_private {
          ~ ip_address        = "10.0.1.100" -> "10.0.1.101"
            # (2 unchanged attributes hidden)
        }

        # (2 unchanged blocks hidden)
    }

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

This is odd because the frontend_private field, the parent field for the private IP address, has ForceNew set to true. However, there seems to be a bug where if the field is a list type and the Elem is of type pluginsdk.Resource, the ForceNew does not get propagated down to the child fields.

This aligns with this comment from an existing issue with the plugin SDK. The comment links this segment of code from the plugin SDK indicating that ForceNew only gets copied from the parent schema when the Elem is of type Schema.

This change adds ForceNew: true to the nested fields whose parents have ForceNew: true. I manually verified that with this change, the bug is now fixed. The terraform plan output from the above example becomes

  # azurerm_nginx_deployment.dep must be replaced
-/+ resource "azurerm_nginx_deployment" "dep" {
      ~ id                        = "/subscriptions/ee920d60-90f3-4a92-b5e7-bb284c3a6ce2/resourceGroups/valyria-tf-test/providers/Nginx.NginxPlus/nginxDeployments/valyria-tf-dep" -> (known after apply)
      ~ ip_address                = "10.0.1.100" -> (known after apply)
      ~ managed_resource_group    = "NGX_valyria-tf-test_valyria-tf-dep_eastus2" -> (known after apply)
        name                      = "valyria-tf-dep"
      ~ nginx_version             = "1.25.1 (nginx-plus-r30-p2)" -> (known after apply)
        tags                      = {
            "env" = "test"
        }
        # (7 unchanged attributes hidden)

      ~ frontend_private {
          ~ ip_address        = "10.0.1.100" -> "10.0.1.101" # forces replacement
            # (2 unchanged attributes hidden)
        }

      ~ identity {
          + principal_id = (known after apply)
          + tenant_id    = (known after apply)
            # (2 unchanged attributes hidden)
        }

        # (1 unchanged block hidden)
    }

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

PR Checklist

• I have followed the guidelines in our Contributing Documentation.
• I have checked to ensure there aren't other open Pull Requests for the same update/change.
• I have checked if my changes close any open issues. If so please include appropriate closing keywords below.
• I have updated/added Documentation as required written in a helpful and kind way to assist users that may be unfamiliar with the resource / data source.
• I have used a meaningful PR title to help maintainers and other users understand this change and help prevent duplicate work.
  For example: “resource_name_here - description of change e.g. adding property new_property_name_here”

Changes to existing Resource / Data Source

• I have added an explanation of what my changes do and why I'd like you to include them (This may be covered by linking to an issue above, but may benefit from additional explanation).
• I have written new tests for my resource or datasource changes & updated any relevent documentation.
• I have successfully run tests with my changes locally. If not, please provide details on testing challenges that prevented you running the tests.
• (For changes that include a state migration only). I have manually tested the migration path between relevant versions of the provider.

Testing

• My submission includes Test coverage as described in the Contribution Guide and the tests pass. (if this is not possible for any reason, please include details of why you did or could not add test coverage)

Change Log

Below please provide what should go into the changelog (if anything) conforming to the Changelog Format documented here.

• azurerm_nginx_deployment- add ForceNew to nested fields

This is a (please select all that apply):

• Bug Fix
• New Feature (ie adding a service, resource, or data source)
• Enhancement
• Breaking Change

[mbfrahry]

Hey @valyria257, thanks for catching this! This change does look good but we should also update the documentation to reflect that changing these values will force a new resource to be created.

[valyria257]

Hi @mbfrahry, I see the docs already say "Changing this forces a new NGINX Deployment to be created" for frontend_private, frontend_public, and network_interface example in docs. Do each of the child fields also need to say this, or is it implied?

[mbfrahry]

Hi @valyria257, so you will need to add it to each of the child fields. There are cases where adding or removing a new block forces a new resource to be created but you can modify the child attributes without issue. This is the case where adding and removing a block and modifying the child attributes forces a new resource to be created so the docs should be updated to reflect that.

[valyria257]

Makes sense @mbfrahry, I updated the docs accordingly!

[stephybun]

Thanks @valyria257 LGTM 👍