Order of actions is incorrect when applying a config that removes a resource that is referenced by another resource

[shinmog]

Terraform Version

Terraform v0.12.29

Your version of Terraform is out of date! The latest version
is 0.13.2. You can update by downloading from https://www.terraform.io/downloads.html

Terraform Configuration Files

Initial deployment config:

provider "panos" {
    hostname = "192.168.1.1"
    username = "admin"
    password = "admin"
}

resource "panos_address_object" "a" {
    name = "name a"
    value = "192.168.192.167/24"
}

resource "panos_address_object" "b" {
    name = "name b"
    value = "192.168.192.168/24"
}

resource "panos_address_object" "c" {
    name = "name c"
    value = "192.168.192.169/24"
}

resource "panos_address_group" "x" {
    name = "my tf group"
    static_addresses = [
        panos_address_object.a.name,
        panos_address_object.b.name,
        panos_address_object.c.name,
    ]
}

Update config (and thus this GitHub issue):

provider "panos" {
    hostname = "192.168.1.1"
    username = "admin"
    password = "admin"
}

resource "panos_address_object" "a" {
    name = "name a"
    value = "192.168.192.167/24"
}

resource "panos_address_object" "b" {
    name = "name b"
    value = "192.168.192.168/24"
}

resource "panos_address_group" "x" {
    name = "my tf group"
    static_addresses = [
        panos_address_object.a.name,
        panos_address_object.b.name,
    ]
}

Debug Output

https://gist.github.com/shinmog/a09c3f2c23da7ec2d3761b0156d9f2ee

Crash Output

N/A

Expected Behavior

Terraform needs to:

1. remove the reference to address object C from the group X
2. then remove address object C

Actual Behavior

Terraform wants to delete address object C first, which it can't since group X is referencing it.

Steps to Reproduce

1. terraform init (with first config)
2. terraform apply (with first config)
3. terraform apply (with second config)

Additional Context

I've also tried changing the resource references to depends_on to see if Terraform would behave differently, but the same thing happens.

References

• Address Groups and Address Objects deletion errors on apply PaloAltoNetworks/terraform-provider-panos#234

[annakhm]

We are experiencing same kind of issue with terraform-provider-nsxt. Still happens with terraform 0.13.

[jbardin]

Hi @shinmog,

Sorry about the confusion here, but this is the correct default order of operations for Terraform.
It will help to view this from the order imposed by a replacement of the resource, which would be:

• delete existing panos_address_object
• create new panos_address_object
• update panos_address_group

In this case you can see that you would have the same problem, where the first operation would fail because the panos_address_group has not been updated. This is where you would use create_before_destroy to change the lifecycle of the panos_address_object, so that the order of operations changes to

• create new panos_address_object
• update panos_address_group
• delete existing panos_address_object

From here, you can see that with only the removal of the panos_address_object, this still provides you with the order you want.

The major caveat here is that the removal-only case will only work in 0.13. Prior to 0.13 you will have to manually fixup the resources or use -target to apply them in the desired order.

We use GitHub issues for tracking bugs and enhancements, rather than for questions. While we can sometimes help with certain simple problems here, it's better to use the community forum where there are more people ready to help. The GitHub issues here are monitored only by our few core maintainers.

Based on the information you've provided, it looks like this doesn't represent a specific bug or feature request, even though I understand that Terraform isn't doing what you expect it to, and so I'm going to close it. Please do feel free to ask your question in the community forum. Thanks!

[annakhm]

Hello @jbardin, I don't think create_before_destroy would fix the above problem (at least it doesn't in similar case we see in nsxt provider). I think the reason is that panos_address_group is not re-created, but updated in place, and panos_address_object only needs to be deleted. Could you please comment on this? Thanks much.

[jbardin]

@annakhm, The order listed above covers this, just skip the "create" step which isn't present, and you have

• update panos_address_group
• delete existing panos_address_object

[annakhm]

Thank you @jbardin! Indeed that works, however I found that lifecycle clause only catches if it is present during object creation. I'm guessing this is by design, it would be helpful though to see a warning about this when applying an update that contains lifecycle changes.

[jbardin]

Ah yes, we have an issue covering that here (#25473) for anyone interested.

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