wait_for_ssl_pending_validation causes resource recreation

[Evesy]

Confirmation

• My issue isn't already found on the issue tracker.
• I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version

Terraform v1.3.2
on linux_amd64

• provider registry.terraform.io/hashicorp/cloudflare v3.27.0

Affected resource(s)

cloudflare_custom_hostname

Terraform configuration files

resource "cloudflare_custom_hostname" "custom_hostname" {
  hostname             = "hostname"
  custom_origin_server = "origin"
  zone_id              = cloudflare_zone.default.id
  ssl {
    certificate_authority = "google"
    method                = "http"
    type                  = "dv"
    wildcard              = "false"
    settings {
      min_tls_version = "1.2"
    }
  }
}

Link to debug output

https://gist.github.com/Evesy/e7316dca485eb58d84af6556feb0de12

Panic output

No response

Expected output

Existing Custom Hostname is deployed with the below resource definition:

resource "cloudflare_custom_hostname" "custom_hostname" {
  hostname             = "hostname"
  custom_origin_server = "origin"
  zone_id              = cloudflare_zone.default.id
  ssl {
    method                = "http"
    type                  = "dv"
    wildcard              = "false"
    settings {
      min_tls_version = "1.2"
    }
  }
}

I then add a new SSL flag to set a different certificate authority, so the resource becomes:

resource "cloudflare_custom_hostname" "custom_hostname" {
  hostname             = "hostname"
  custom_origin_server = "origin"
  zone_id              = cloudflare_zone.default.id
  ssl {
    certificate_authority = "google"
    method                = "http"
    type                  = "dv"
    wildcard              = "false"
    settings {
      min_tls_version = "1.2"
    }
  }
}

Terraform should patch the custom hostname to update the CA

Actual output

Terraform wants to recreate the resource due to the wait_for_ssl_pending_validation parameter. This is true whether I leave this unset, or set to true/false

  # cloudflare_custom_hostname.custom_hostname_default["www"] must be replaced
-/+ resource "cloudflare_custom_hostname" "custom_hostname_default" {
      ~ id                              = "668b3336-d15e-4d32-92cd-e414d9f214e5" -> (known after apply)
      ~ ownership_verification          = {
          - "name"  = ""
          - "type"  = ""
          - "value" = ""
        } -> (known after apply)
      ~ ownership_verification_http     = {
          - "http_body" = ""
          - "http_url"  = ""
        } -> (known after apply)
      + status                          = (known after apply)
      + wait_for_ssl_pending_validation = false # forces replacement
        # (2 unchanged attributes hidden)

      ~ ssl {
          ~ certificate_authority = "digicert" -> "google"
          ~ status                = "active" -> (known after apply)
          ~ validation_errors     = [] -> (known after apply)
          ~ validation_records    = [] -> (known after apply)
            # (3 unchanged attributes hidden)

          ~ settings {
              - ciphers         = [] -> null
                # (1 unchanged attribute hidden)
            }
        }
    }

Steps to reproduce

• Deploy Custom Hostname with initial configuration above on TF provider version < 3.26.0
• Update to TF provider version >= 3.26.0
• Modify SSL settings on custom hostname resource
• Run plan

Additional factoids

No response

References

No response

[github-actions]

Terraform debug log detected ✅

[Evesy]

Should ForceNew here in fact be set to false?

[jacobbednarz]

we can definitely remove that for the sake of defaults however, i think if you set wait_for_ssl_pending_validation going forward, you expect it to recreate certificates as you would have a pipeline pending on it to populate records, etc.

[Evesy]

Whether to wait for a custom hostname SSL sub-object to reach status pending_validation during creation

Based on the description, specifically during creation, I would only expect the wait behaviour to be enacted when the resource is being created. In the case of changing CA's, any pipeline being used off the back of it to e.g. populate records will certainly need to be retriggered; but in our case I wouldn't want the resource to be recreated as that will involve an amount of downtime, vs not recreating in which case Cloudflare will continue to serve the old certificate until the new one is ready.

I don't have any strong opinion around how it should work, but I do think when unset/set to false, it shouldn't trigger a recreate on the resource, it should just PATCH the resource to mirror the API

[jacobbednarz]

for a workaround, you can add the field to your state file manually and set it to false.

i'll have a chat with the team whether we should remove this for now.

[Evesy]

for a workaround, you can add the field to your state file manually and set it to false.

This did the trick, thanks

[github-actions]

This functionality has been released in v3.29.0 of the Terraform Cloudflare Provider.

Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!