4.39.0 to 4.41.0: the cloudflare_record no longer has the value argument and results in all of these resources needing to add it back
#3915
Comments
nitrocode
added
kind/bug
Community NoteVoting for Prioritization
Volunteering to Work on This Issue
|
|
Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of This issue has been marked with |
github-actions
bot
added
triage/needs-information
|
|
|
We do not see a deprecation notice in our plan. Instead, we see 100s of our cloudflare records trying to re-add the This is likely a provider bug and gives us far less confidence in keeping a I know open source can be difficult, grueling, and thankless. While I appreciate all of your work (thank you!) and others who contribute to this repo, closing this issue with a terse response and without a conversation, at the very least, is not the most helpful approach in community engagement. Please at least acknowledge the issue and if this is not a provider bug, perhaps offer a path forward for myself and others who may be in the same predicament. |
|
the issue is closed as there isn't anything actionable for maintainers. it doesn't stop discussion or questions of there are still ones outstanding. if an issue is discovered, the issue can always be re-opened and actions assigned. as for your specific issue, the reproduction case is based on HCL dynamics which we call out in the issue template to avoid as not something we are able to reproduce/debug due to potentially having it's own logic bugs so i would start with a reproduction case that isn't using the module and go from there. worth noting as well, you haven't provided required debug logs which really hampers what anyone can do to help you here. when issues are raised lacking context, it's the equivalent looking for a light switch, in someone else's house in the pitch black of night. any discovery done is based on assumptions and best guesses which wastes a lot of time which is not a good use of anyone's time. fwiw, we have 4.41.0 running internally with |
|
If you close the issue, most people will take that as a sign to no longer continue the discussing, even if technically we can have a discussion as the issue is not locked. Closing an issue is akin to someone coming to your house to let you know that a part of your home has a hole in it, and you say "okay but I need more information" and then immediately close the door with your ear to the door to continue the chat. :) Technically I can still yell from outside so you can hear me but most people would probably just walk away. That's why I referenced community engagement. As trivial as it is, if you want to continue to discuss the issue, it's best to keep the issue open or at the very least, close it and provide next steps without prompt. I get your point so to continue the discussion, here is a far smaller hcl without a module to reproduce the issue with debug logs and necessary redactions. Please let me know if more information is needed. hclterraform {
required_version = "> 1.0.0"
required_providers {
cloudflare = {
source = "cloudflare/cloudflare"
version = "> 4"
}
}
}
resource "cloudflare_record" "default" {
zone_id = "snip"
name = "meetup"
value = "snip"
# content = "snip"
comment = "snip"
type = "CNAME"
proxied = true
tags = ["terraform"]
}Version command✗ terraform version
Terraform v1.9.5
on darwin_arm64
+ provider registry.terraform.io/cloudflare/cloudflare v4.41.0Import command✗ terraform import cloudflare_record.default snip/snipWith `content`, I see this # cloudflare_record.default will be updated in-place
~ resource "cloudflare_record" "default" {
+ allow_overwrite = false
+ content = "snip"
id = "snip"
name = "snip"
tags = [
"terraform",
]
# (10 unchanged attributes hidden)
}
Plan: 0 to add, 1 to change, 0 to destroy.With `value`, I see this (with deprecation) # cloudflare_record.default will be updated in-place
~ resource "cloudflare_record" "default" {
+ allow_overwrite = false
id = "snip"
name = "snip"
tags = [
"terraform",
]
+ value = "snip"
# (10 unchanged attributes hidden)
}
Plan: 0 to add, 1 to change, 0 to destroy.
╷
│ Warning: Argument is deprecated
│
│ with cloudflare_record.default,
│ on main.tf line 15, in resource "cloudflare_record" "default":
│ 15: value = "snip"
│
│ `value` is deprecated in favour of `content` and will be removed in the next major release.
│
│ (and one more similar warning elsewhere)terraform plan with debug |
|
if you've taken a closed issue that way, i'm sorry but it's your perception. this project along with many others like Homebrew don't operate that way. as for your reproduction, are you only seeing the issue when importing first? or is this only an issue when creating them directly (actually running apply, not plan) |
|
I see this value/content drift issue for our existing root dirs without importing a record. The reproduction case required the import to make it small enough to share. Thank you for looking into this |
|
i'm afraid i'm unable to reproduce this one (without the import which i'm still unsure why it's needed). using your configuration and the following steps what i would recommend is instead of |
|
Could the documentation for the It says:
and
It isn't obvious what is used/needed in the It used to be: But how does it work now? It says we can now only have inside the The documentation doesn't make sense now. |
|
I'm affected by this issue too. Here's how to repeat this issue. I'm using TF 1.2.9 for whatever reason terraform {
required_providers {
cloudflare = {
source = "cloudflare/cloudflare"
version = "4.38.0"
}
}
}
locals {
zone_name = "example.com"
}
provider "cloudflare" {}
data "cloudflare_zone" "this" {
name = local.zone_name
}
resource "cloudflare_record" "this" {
name = "mytest.${local.zone_name}"
priority = 5
proxied = false
ttl = 1
type = "TXT"
value = "this-is-a-test"
zone_id = data.cloudflare_zone.this.id
}
Plan results # cloudflare_record.this will be updated in-place
~ resource "cloudflare_record" "this" {
id = "6553e8exxxxxxc4f2f02ccfa22fd0"
name = "mytest.example.com"
tags = []
+ value = "this-is-a-test"
# (10 unchanged attributes hidden)
}Observations:
Workaround seems to be
So people will need to pin at 4.40, tf apply, before unpinning and tf applying again. Or blindly upgrade and fingers cross there's no drift or other changes to check for. |
|
I was on
... no modified "value" entries from state. I expect there's still migration work for me in near-future 👀 (5.0?) |
|
I just encountered the same issue. I have a module that creates a large number of records using the Performing the workaround described by @joeltheiconic also resolved this for me. |
|
This is still an issue upgraded from 4.36.0 to 4.44.0 |
Confirmation
Terraform and Cloudflare provider version
terraform 1.9.5
provider 4.41.0
Affected resource(s)
cloudflare_record
Terraform configuration files
Link to debug output
N/A
Panic output
N/A
Expected output
No changes
Also I would have expected this deprecation to be in a major version i.e. 5.x instead of a minor version 4.39.0.
Actual output
Steps to reproduce
Additional factoids
Our workaround is to pin the provider until we're ready to migrate
References
No response
The text was updated successfully, but these errors were encountered: