CF support came back to us stating that the issue was that we were explicitly specifying a /32 in our addresses. We confirmed that removing the /32 from our input resolved the issue with the plan tearing the list down and rebuilding it. Looking at the OG post here it appears you're manually specifying an ASN=0, perhaps try removing any ASN=0 from your input.

Here is our current terraform block

resource "cloudflare_list" "ip_whitelist" {
  account_id  = var.cloudflare_account_id
  name        = "ip_whitelist"
  description = "ip_whitelist"
  kind        = "ip"

  dynamic "item" {
    for_each = local.whitelist_data
    content {
      value {
        ip = replace(item.value.Address, "/32", "") 
      }
      comment = item.value.Source
    }
  }
}

from terraform-provider-cloudflare.

We have the same issue on v4.18 and now v4.20 and subsequent apply commands always reset the list even though we dont change anything, seemingly caused by wanting to set the asn = 0 -> null for an IP.

from terraform-provider-cloudflare.

@rickardp the bot comment is not invalid. you have not provided the full debug log output which is used for diagnosis and you're using dynamics which we don't accept for reproduction cases for the reasons mentioned. if you provide the requested details, this can be triaged.

@niklasweimann if you have the debug logs and reproduction case available, we can also use that instead for investigation.

The IP list is from a dynamic source. I don't see why my use case would not be valid. Are you saying that this resource does not work with dynamic blocks and this is by design?

Naturally I am not going to provide a full debug log of my IaC output on the public internet. I kept the part where the versions were printed in the hope that this sufficed. I am happy to provide more details privately if you prefer.

from terraform-provider-cloudflare.

Curious when we can expect this to be resolved. It is generating alot noise in plans that make it easy to overlook other undesirable outcomes. I think we're just going to open a support case on this to hopefully get some eyes on it.

from terraform-provider-cloudflare.

First you create a IP list using cloudflare_list resource

resource "cloudflare_list" "example" {
  account_id  = var.cloudflare_account_id
  name        = "list_test_delete"
  description = "example IPs for a list"
  kind        = "ip"

  item {
    value {
      ip = "192.0.2.0"
    }
    comment = "one"
  }

}

Then, you add a new item inside the same resource

resource "cloudflare_list" "example" {
  account_id  = var.cloudflare_account_id
  name        = "list_test_delete"
  description = "example IPs for a list"
  kind        = "ip"

  item {
    value {
      ip = "192.0.2.0"
    }
    comment = "one"
  }

  item {
    value {
      ip = "192.0.2.1"
    }
    comment = "two"
  }
  
}

Terraform will plan to delete the first one and add all back.

  # cloudflare_list.example will be updated in-place
  ~ resource "cloudflare_list" "example" {
        id          = "<redacted-account-id>"
        name        = "list_test_delete"
        # (3 unchanged attributes hidden)

      - item {
          - comment = "one" -> null

          - value {
              - asn = 0 -> null
              - ip  = "192.0.2.0" -> null
            }
        }
      + item {
          + comment = "one"

          + value {
              + ip = "192.0.2.0"
            }
        }
      + item {
          + comment = "two"

          + value {
              + ip = "192.0.2.1"
            }
        }
    }

Here is the associated gist: https://gist.github.com/7jPUn4w8caDX/241ad64c031a386fe8bfc1ab8e4e6ca8

from terraform-provider-cloudflare.

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

from terraform-provider-cloudflare.

Terraform debug log detected ✅

from terraform-provider-cloudflare.

Thank you for opening this issue and sorry to hear you're hitting issues. Unfortunately, the reproduction case provided contains HCL dynamic expressions. Examples of these are:

• Conditionals
• For loops
• Dynamic blocks
• Modules and module references

Maintainers don't accept these as reproduction cases since using these constructs and expressions can hold their own logic bugs which are outside of the provider and not able to be diagnosed.

For maintainers to triage this issue, we recommend providing a minimal reproduction test case that is only contains the impacted resources and can be easily reproduced in an isolated environment. Without providing this, maintainers are limited in what support they can provide.

from terraform-provider-cloudflare.

Unfortunately, the reproduction case provided contains HCL dynamic expressions

Can we get a maintainer to look at this please? The bot comment above is invalid, as this issue might be caused by the dynamic expressions and this must work. The repro case above is self contained and is expected to work.

from terraform-provider-cloudflare.

We are experiencing the same issue. It seems that it is related to kind="ip" as the API returns ASN as 0 on subsequent runs, but ASN is null in the Terraform state which results in a change required by Terraform. Setting ASN to 0 does not mitigate the issue as 0 is not allowed as an ASN.

from terraform-provider-cloudflare.

@rickardp the bot comment is not invalid. you have not provided the full debug log output which is used for diagnosis and you're using dynamics which we don't accept for reproduction cases for the reasons mentioned. if you provide the requested details, this can be triaged.

@niklasweimann if you have the debug logs and reproduction case available, we can also use that instead for investigation.

from terraform-provider-cloudflare.

Hey @rickardp 👋
Here the debug log of an RUN which results in the described change. I have removed all ips, Entries not Related to the cloudflare_list and sensitive data:
log.txt

from terraform-provider-cloudflare.

Hey @rickardp 👋 Here the debug log of an RUN which results in the described change. I have removed all ips, Entries not Related to the cloudflare_list and sensitive data: log.txt

Thank you, @niklasweimann I can confirm this shows the same behaviour as I had.

@jacobbednarz Is anyone looking into this issue?

from terraform-provider-cloudflare.

This seems to be a bug in the update logic for cloudflare list items, resulting in erroneous reordering of entries when there are in fact no changes. This is not reproducible without the for_each statement, because a list with only one item is always in the same order.

from terraform-provider-cloudflare.