terraform-provider-cloudflare icon indicating copy to clipboard operation
terraform-provider-cloudflare copied to clipboard

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

Open nightpool opened this issue 1 year ago • 3 comments

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:

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 avatar Oct 11 '24 16:10 nightpool

Terraform debug log detected :white_check_mark:

github-actions[bot] avatar Oct 11 '24 16:10 github-actions[bot]

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.

github-actions[bot] avatar Oct 11 '24 16:10 github-actions[bot]

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

nightpool avatar Oct 11 '24 17:10 nightpool

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 avatar Oct 28 '24 15:10 rquadling

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!

rquadling avatar Oct 28 '24 15:10 rquadling

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

xs2bharat avatar Nov 16 '24 19:11 xs2bharat

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.

mikealbert avatar Nov 20 '24 16:11 mikealbert

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.

MiticoBerna avatar Nov 21 '24 09:11 MiticoBerna

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.

rquadling avatar Nov 21 '24 10:11 rquadling

@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

mikealbert avatar Nov 21 '24 13:11 mikealbert

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.

MiticoBerna avatar Nov 22 '24 15:11 MiticoBerna

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

xs2bharat avatar Nov 22 '24 17:11 xs2bharat

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.

mgreenj avatar Dec 06 '24 18:12 mgreenj

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!

jhutchings1 avatar Apr 14 '25 23:04 jhutchings1