Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ignore_changes doesn't work as documented/intended with count/for_each #29447

Closed
dpittner opened this issue Aug 23, 2021 · 3 comments
Closed
Labels
bug new new issue not yet triaged

Comments

@dpittner
Copy link

dpittner commented Aug 23, 2021

in various variants, I'm not able to ignore changes to attributes of resources that use count of for_each. e.g.

resource "ibm_is_network_acl" "multizone_acl" {
  for_each       = var.acl_rules_map
  name           = "${var.unique_name}-${each.key}-2-others-acl"
  vpc            = ibm_is_vpc.vpc.id
  resource_group = var.resource_group_id
  lifecycle {
    ignore_changes = [
      # Ignore changes to state of rule
      rules["subnets"]
    ]
  }

  # Create ACL rules
  dynamic "rules" {
    for_each = flatten([local.acl_rules, each.value])
    content {
      name        = rules.value.name
      action      = rules.value.action
      source      = rules.value.source

the example above will still cause a change after applying and re-planing. Change will look alike:


~ resource "ibm_is_network_acl" "multizone_acl" {
        id                      = "r006-20a56ecc-6dcd-41ac-be1a-682cc2afab8f"
        name                    = "example-vpc-private-2-others-acl"
        tags                    = []
        # (6 unchanged attributes hidden)

      ~ rules {
            id          = "2e7f8e46-108c-4ac2-9d4a-43fc80aa07cf"
            name        = "allow-traffic-subnet-edge-inbound"
          ~ subnets     = 0 -> 3
            # (5 unchanged attributes hidden)
        }

per the ignore_changes above I'd not expect this change to be made.

I can't yet offer a repro case, will add that if it helps, would assume the issue in the aforementioned issue still persists.

Terraform Version

Terraform v1.0.5

...

Terraform Configuration Files

...

Debug Output

Crash Output

Expected Behavior

Actual Behavior

Steps to Reproduce

Additional Context

References

Appears to be same as: #21941

@dpittner dpittner added bug new new issue not yet triaged labels Aug 23, 2021
@apparentlymart
Copy link
Contributor

Hi @dpittner! Thanks for reporting this.

I expect that the reason for the behavior you saw is that the provider has declared this rules block as being backed by some sort of collection in the object value that results from decoding this configuration, and so rules.subnets doesn't really match anything because the rules value itself is a collection of objects.

I'm not familiar with this particular provider, but assuming I found the correct source code it looks like rules is declared as a list, in which case you'll need to specify which of the rules objects you want to ignore subnets in:

  ignore_changes = [
    rules[0].subnets,
    rules[1].subnets,
  ]

Since you are building rules blocks dynamically here, using dynamic "rules", I expect you don't know ahead of time which indices are present and so you probably want to ignore all of them. In that case, the best option available with the current design of ignore_changes is to ignore all rules blocks altogether, like this:

  ignore_changes = [
    rules,
  ]

I expect you'd rather have a way to say "ignore subnets for all rules blocks", which is what #29394 is about and so I'm going to close this issue as a duplicate of that one. What you've seen here is the current intended behavior of Terraform (ideally it would've returned you an error saying that rules is not a valid attribute of a list, but that's a backward-compatibility constraint) and we'll use that other issue to discuss ways to make the feature more useful in dynamic cases.

Thanks again!

@dpittner
Copy link
Author

Thanks for the excellent explanation! Yeah, as you suspect we can't really ignore rules in general, they've other attributes we need to adjust if they change.

@github-actions
Copy link
Contributor

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 24, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug new new issue not yet triaged
Projects
None yet
Development

No branches or pull requests

2 participants