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

v5.0.0 does not detect configuration drift #4984

Closed
3 tasks done
jimnor0xF opened this issue Jan 30, 2025 · 11 comments
Closed
3 tasks done

v5.0.0 does not detect configuration drift #4984

jimnor0xF opened this issue Jan 30, 2025 · 11 comments
Labels
version/5 Categorizes issue or PR as related to version 5 of the provider.

Comments

@jimnor0xF
Copy link

jimnor0xF commented Jan 30, 2025

Confirmation

  • This is a bug with an existing resource and is not a feature request or enhancement. Feature requests should be submitted with Cloudflare Support or your account team.
  • I have searched the issue tracker and my issue isn't already found.
  • I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version

Terraform v1.10.5 on darwin_arm64

  • provider registry.terraform.io/cloudflare/cloudflare v5.0.0

Affected resource(s)

  • cloudflare_dns_record
  • cloudflare_zero_trust_access_application
  • And likely more

Terraform configuration files

 resource "cloudflare_dns_record" "example_dns_record" {
  zone_id = "REDACTED"
  comment = "Test record"                        
  content = "blabla"                                            
  name = "stuff.test.io.internal.redacted.net"                  
  type = "CNAME"
  proxied = true
  ttl = 1
}

Link to debug output

https://gist.github.com/jimnor0xF/a8bb6ab7e3cef0593b6c4253e77de6df

Panic output

No response

Expected output

So what was done here is that I applied the above resource then changed the name attribute from stuff.test.io.internal.redacted.net to shoulddetectchange.test.io.internal.redacted.net manually in Cloudflare Dashboard.

Record is fetched according to attached debug log in gist, but Terraform does not report any changes.

In v4, changes are detected, but not in v5 it seems. Is this intended?

Actual output

$ terraform plan

cloudflare_dns_record.example_dns_record: Refreshing state... [id=4765cbfe3b2dcc6e793ad27447d88b9e]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.
@jimnor0xF jimnor0xF changed the title v5.0.0 does not detect drift for cloudflare_dns_record v5.0.0 does not detect configuration drift for cloudflare_dns_record Jan 30, 2025
@jacobbednarz
Copy link
Member

this isn't intentional and maybe a side effect of our custom marshaler. i'll take a look but in the meantime, if you manage the resource just with terraform, you can avoid this one.

@jimnor0xF
Copy link
Author

Noticed this happens with cloudflare_zero_trust_access_application as well. So perhaps affects all resources in v5

@devin-purple
Copy link

Probably, this is also happening with rulesets. After making changes in the UI, running plan doesn't report any changes.

@jimnor0xF jimnor0xF changed the title v5.0.0 does not detect configuration drift for cloudflare_dns_record v5.0.0 does not detect configuration drift Feb 4, 2025
@devin-purple
Copy link

#5032 ?

@dackerman
Copy link
Contributor

#5032 ?

@devin-purple yes, that is a change that we plan to make in a future release that should address this, but a little testing is needed first to check for fields that need to be "normalized" to avoid being overzealous with drift detection.

@jacobbednarz jacobbednarz added the version/5 Categorizes issue or PR as related to version 5 of the provider. label Feb 21, 2025
@jacobbednarz jacobbednarz marked this as a duplicate of #5164 Feb 25, 2025
@kaincosta
Copy link

The same is happening with the cloudflare_ruleset resource, I created a ticket for it but it's actually a duplicate of this one, still, good to track the issue for that resource.
#5164

@kaincosta
Copy link

@jacobbednarz is there a timeframe of when the fix might be coming out?

@Piethan
Copy link

Piethan commented Feb 25, 2025

The cloudflare_page_rule is also affected.

@natemccurdy
Copy link

This bug also affects the cloudflare_load_balancer resource.

I changed the endpoints in a Terraform-managed load balancer using the web Console, but the pools configured via default_pools in Terraform did not report any drift after running terraform plan.

The load balancer has two pools (i.e. endpoints) configured in Terraform:

default_pools = [<pool_1_id>, <pool_2_id>]

And in the web console, I removed one of the endpoints.
I expected a terraform plan to show that drift and show that the LB should have two endpoints defined.

Here's a snippet from the debug log:

2025-02-26T11:01:01.772-0800 [DEBUG] provider.terraform-provider-cloudflare_v5.1.0: Value switched to prior value due to semantic equality logic: @module=sdk.framework tf_provider_addr=registry.terraform.io/cloudflare/cloudflare tf_req_id=4255bc91-85de-a35c-d23e-2897dc7ec9f6 tf_rpc=ReadResource @caller=github.com/hashicorp/terraform-plugin-framework@v1.13.0/internal/fwschemadata/value_semantic_equality.go:91 tf_attribute_path=default_pools[0] tf_resource_type=cloudflare_load_balancer timestamp=2025-02-26T11:01:01.772-0800
2025-02-26T11:01:01.772-0800 [DEBUG] provider.terraform-provider-cloudflare_v5.1.0: Value switched to prior value due to semantic equality logic: tf_rpc=ReadResource @module=sdk.framework tf_attribute_path=default_pools tf_provider_addr=registry.terraform.io/cloudflare/cloudflare tf_req_id=4255bc91-85de-a35c-d23e-2897dc7ec9f6 tf_resource_type=cloudflare_load_balancer @caller=github.com/hashicorp/terraform-plugin-framework@v1.13.0/internal/fwschemadata/value_semantic_equality.go:91 timestamp=2025-02-26T11:01:01.772-0800

Notably, the message "Value switched to prior value due to semantic equality logic" seems suspicious here.

@jacobbednarz
Copy link
Member

fixed by #5223

@kaincosta
Copy link

Good morning @jacobbednarz, has the fix being release? the latest provider version on the CF provider repo is still 5.1.0 and the issue is still present in that one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
version/5 Categorizes issue or PR as related to version 5 of the provider.
Projects
None yet
Development

No branches or pull requests

7 participants