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

Imported cloudflare_records don't have their content available, misleading plan is generated #4280

Open
3 tasks done
nightpool opened this issue Oct 11, 2024 · 13 comments
Open
3 tasks done
Labels
kind/bug Categorizes issue or PR as related to a bug. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. triage/debug-log-attached Indicates an issue or PR has a complete Terraform debug log.

Comments

@nightpool
Copy link

nightpool commented Oct 11, 2024

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

plan showing no content in the existing resource API response showing content

Steps to reproduce

  1. Import a Cloudflare resource
  2. See that the content is marked as added, not changed

Additional factoids

No response

References

No response

@nightpool nightpool added kind/bug Categorizes issue or PR as related to a bug. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Oct 11, 2024
Copy link
Contributor

Terraform debug log detected ✅

@github-actions github-actions bot added the triage/debug-log-attached Indicates an issue or PR has a complete Terraform debug log. label Oct 11, 2024
Copy link
Contributor

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.

@nightpool
Copy link
Author

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

@rquadling
Copy link

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.

@rquadling
Copy link

rquadling commented Oct 28, 2024

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!

@xs2bharat
Copy link

xs2bharat commented Nov 16, 2024

I am having same issue using command terraform plan -generate-config-out="generated.tf"
image

content being null is causing terraform to apply these changes even though there shouldn't be any delta

@mikealbert
Copy link

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.

@MiticoBerna
Copy link

MiticoBerna commented Nov 21, 2024

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

@rquadling
Copy link

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.

@mikealbert
Copy link

@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.39 and record using value
  • Bump provider to 4.41 and swap content for value

@MiticoBerna
Copy link

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.39 and record using value
  • Bump provider to 4.41 and swap content for value

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.

@xs2bharat
Copy link

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

@0x0M03II
Copy link

0x0M03II commented Dec 6, 2024

We were experiencing the same issue and the solution above worked for us as well.

  1. Import records with provider pinned to version 4.39
  2. Change provider version to 4.41, and swap content for value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. triage/debug-log-attached Indicates an issue or PR has a complete Terraform debug log.
Projects
None yet
Development

No branches or pull requests

6 participants