terraform-provider-cloudflare
terraform-provider-cloudflare copied to clipboard
Imported cloudflare_records don't have their content available, misleading plan is generated
Confirmation
- [X] 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.
- [X] I have searched the issue tracker and my issue isn't already found.
- [X] I have replicated my issue using the latest version of the provider and it is still present.
Terraform and Cloudflare provider version
Terraform v1.9.5
on darwin_arm64
+ provider registry.terraform.io/cloudflare/cloudflare v4.43.0
Affected resource(s)
cloudflare_record
Terraform configuration files
import {
to = cloudflare_record.dmarc
id = "2920f514b6185d3acad99fb8135d2b72/72686dd3762bc9ad2d60511a43ca01c9"
}
resource "cloudflare_record" "dmarc" {
zone_id = "2920f514b6185d3acad99fb8135d2b72"
type = "TXT"
name = "_dmarc"
content = "v=DMARC1; p=none; rua=mailto:[email protected]"
comment = "SES DMARC record for genius.com"
}
Link to debug output
https://gist.githubusercontent.com/nightpool/4ec2e14cb876b26afd3cff8e64dd74d8/raw/ee0dd8c5ecd9c883e2fdeed8335873f4e9653500/tf%2520debug%2520log
Panic output
No response
Expected output
Plan should show that content is unchanged, or it should show the change in content if one exists
Actual output
content is unconditionally marked as added, not (changed/unchanged), even when the content of the record is identical in the API:
Steps to reproduce
- Import a Cloudflare resource
- See that the
contentis marked as added, not changed
Additional factoids
No response
References
No response
Terraform debug log detected :white_check_mark:
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.
Was not able to reproduce with v5 alpha, the same configuration generated a crash instead. Probably a different bug, since I don't even see any API requests in the log output: https://gist.github.com/nightpool/9dff9062ffdf69c558fc0507f5c88af3
Is this related to the deprecation of the value property in favour of content. I changed the property from value to content and all the records got the property added to the state. In looking at the provider's Go code, if content is present it is used. So it looks like a 2 step upgrade to the state is what actually happens and not a change in the API call.
I think.
This was using v4.44.0. Untested but changelogs related to v4.40.0 do suggest a mixup in how the deprecation was handled.
Also, the cloudflare_record resource in V4 is, by the looks of it, becoming cloudflare_dns_record in v5.0.0-alpha-1.
BUT the current v5 still has the value property.
In short, do NOT use v5 for production as there are other things not present and it IS an alpha release. So subject to almost 100% change!
I am having same issue using command terraform plan -generate-config-out="generated.tf"
content being null is causing terraform to apply these changes even though there shouldn't be any delta
I'm running into this as well. Pinning to provider version 4.39 allowed for a clean import when value was set. Not sure that's a great solution since value will eventually be replaced by content.
I'm running into this as well. Pinning to provider version
4.39allowed for a clean import whenvaluewas set. Not sure that's a great solution sincevaluewill eventually be replaced bycontent.
I tried with 4.39 but I have the same problem, I changed content with value but after the import I've:
~ resource "cloudflare_record" "dns_records" {
+ allow_overwrite = false
id = "4e09b43xxxxxxxx7a290363xxx41"
name = "example.com"
tags = []
+ value = "example.com"
# (10 unchanged attributes hidden)
}
I would have liked to see a change on value and not the add.
EDIT: I used terragrunt plan -refresh=false to speedup the checks, and I saw the diff, but after retried terragrunt plan the diff has disappeared.
Atm I use content with version 4.4.0 and there is no drift after the import.
Move to 4.41.0 minimum.
resource/cloudflare_record: handle scenarios where content and value are both being set in state and erroneously always thinking the content field is the source of truth (https://github.com/cloudflare/terraform-provider-cloudflare/issues/3776)
From all the use cases I've seen, this is the minimum version for cloudflare_record.
@MiticoBerna I have a large number of records to import so I'm trying to generate clean plans to verify my definitions are correct. It seems like I'll need a 2 step process to import with no diff and avoid drift on subsequent plans?
- Import with pinned provider at
4.39and record usingvalue - Bump provider to
4.41and swapcontentforvalue
Move to 4.41.0 minimum.
resource/cloudflare_record: handle scenarios where content and value are both being set in state and erroneously always thinking the content field is the source of truth (#3776)
From all the use cases I've seen, this is the minimum version for
cloudflare_record.
I tried with 4.41.0 but I have the same issue, the plan always tries to add content even if is the same.
Before 1 week ago I had no cloudflare_record inside my state, so I think for me it's safe to use 4.40.0.
@MiticoBerna I have a large number of records to import so I'm trying to generate clean plans to verify my definitions are correct. It seems like I'll need a 2 step process to import with no diff and avoid drift on subsequent plans?
- Import with pinned provider at
4.39and record usingvalue- Bump provider to
4.41and swapcontentforvalue
I just set the version to 4.40.0, added my terragrunt configuration, ran the imports and no drifts about cloudflare_record (using directly content).
Like you, I'm importing all my 60+ zones inside the state with all the records.
This has worked for me. Thanks @mikealbert
Import with pinned provider at 4.39 and record using value Bump provider to 4.41 and swap content for value
We were experiencing the same issue and the solution above worked for us as well.
- Import records with provider pinned to version 4.39
- Change provider version to 4.41, and swap content for value.
Thank you for your bug report! We are not doing active development on the v4 Terraform providers at this time. If you can reproduce this on v5, please reopen your issue and we can have a look there. Thank you!