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

TF13: data.cloudflare_zones reports changes on every plan #764

Closed
threemachines opened this issue Aug 12, 2020 · 6 comments · Fixed by #869
Closed

TF13: data.cloudflare_zones reports changes on every plan #764

threemachines opened this issue Aug 12, 2020 · 6 comments · Fixed by #869
Labels
kind/bug Categorizes issue or PR as related to a bug. triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@threemachines
Copy link

Terraform Version

Terraform v0.13.0

Affected Resource(s)

  • cloudflare_zones

Terraform Configuration Files

terraform {
  required_providers {
    cloudflare = {
      source = "terraform-providers/cloudflare"
    }
  }
  required_version = ">= 0.13"
}

provider "cloudflare" {
  version = "= 2.9.0"
  email   = "redacted"
  api_key = "redacted"
}

data "cloudflare_zones" "test" {
  filter {
    name = "somedomain.com"
  }
}

Expected Behavior

Repeated plans should report no changes.

Actual Behavior

Every plan shows a change for the data source:

Terraform will perform the following actions:

  # data.cloudflare_zones.test will be read during apply
  # (config refers to values not yet known)
 <= data "cloudflare_zones" "test"  {
      ~ id    = "2020-08-12 22:31:04.158252 +0000 UTC" -> "2020-08-12 22:31:04.758952 +0000 UTC"
        zones = [
            {
                id   = "redacted"
                name = "somedomain.com"
            },
        ]

        filter {
            lookup_type = "exact"
            name        = "somedomain.com"
            paused      = false
        }
    }

Plan: 0 to add, 0 to change, 0 to destroy.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  1. terraform init
  2. terraform plan -out terraform.plan
  3. terraform apply terraform.plan
  4. terraform plan

References

This looks like basically the same issue as hashicorp/terraform-provider-aws#14579?

@jacobbednarz
Copy link
Member

Thanks for this; For now, let's see if this gets addressed in 0.13.x core instead of each provider and if it doesn't we can look to update this within the provider itself.

@ionosphere80
Copy link

Same issue with Terraform 0.13.2.

@Rude-Monkey
Copy link

Hi! If I'm not mistaken, they patched something similar on the core side in June (hashicorp/terraform#25302).
Sounds like they are expecting further fixes to be made on the provider side.

@trjstewart
Copy link
Contributor

+1 We're running into this too.

@pecigonzalo
Copy link
Contributor

@jacobbednarz This does not seem to be backported to 0.13.x, could we perform a fix like its done in hashicorp/terraform-provider-aws#15399 and hashicorp/terraform-provider-google#7375 ? I was taking a stab at it, but I was unsure on what to use for things like data_source_zones which returns multiple resource. Maybe a hash of the result?

@jacobbednarz
Copy link
Member

For the data sources where we have multiple values returned, we'll need to ensure we take all of the IDs, join them and hash the value. If we don't do that, the provider won't ever update the ID in the event changes are present on the remote APIs end. By the looks of things, all of the provider data sources are impacted by this.

@jacobbednarz jacobbednarz added the triage/accepted Indicates an issue or PR is ready to be actively worked on. label Nov 12, 2020
boekkooi-lengoo pushed a commit to boekkooi-lengoo/terraform-provider-cloudflare that referenced this issue Feb 28, 2022
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. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants