cloudflare_argo Tiered Caching only = "HTTP status 401: invalid credentials"

[stractenberg-newell]

Terraform Version

v0.12.26

Affected Resource(s)

cloudflare_argo

Terraform Configuration Files

resource "cloudflare_argo" "argo" {
  zone_id        = "${cloudflare_zone.zone.id}"
  tiered_caching = "on"
}

Debug Output

https://gist.github.com/stractenberg-newell/75c8041e83fadfdf91a2a20be60e34d4

Expected Behavior

It should enable Argo "Tiered Caching"

Actual Behavior

I got an error that I'm not entitled for Argo "Smart Routing"

Steps to Reproduce

1. terraform apply

Important Factoids

My TF code works perfectly without the "cloudflare_argo" resource. As soon as I add it, it fails.

We have access to "Tiered Caching" as part of our Enterprise plan and can enable it manually via the console. We do not have access to "Smart Routing" as part of our plan.

If the resource is going to behave this way, documentation should mention that you can only use "cloudflare_argo" if you are entitled for Smart Routing.

[jacobbednarz]

Can you please post the full debug log (only sensitive details redacted) and the code you’re using to reproduce the issue?

[stractenberg-newell]

https://gist.github.com/stractenberg-newell/2e53a30c25b4ee0fc89c523da1d185a7

Enable "Always use HTTPS" and "WAF"

resource "cloudflare_zone_settings_override" "zone" { zone_id = "${cloudflare_zone.zone.id}"

settings { always_use_https = "on" waf = "on" http2 = "on" min_tls_version = "1.2" brotli = "on" polish = "lossless" webp = "on" security_level = "high" opportunistic_encryption = "on" automatic_https_rewrites = "on" ssl = "full" sort_query_string_for_cache = "on" always_online = "off" h2_prioritization = "on" minify { css = "on" js = "on" html = "on" } } }

Add DNS records

resource "cloudflare_record" "apex" { zone_id = "${cloudflare_zone.zone.id}" name = "@" value = "${var.origin_ip}" type = "${var.origin_type}" ttl = 1 proxied = "true" }

Disable Universal SSL

resource "null_resource" "universal_ssl" { provisioner "local-exec" { command = <<EOH curl -X PATCH "https://api.cloudflare.com/client/v4/zones/${cloudflare_zone.zone.id}/ssl/universal/settings" \ -H "X-Auth-Email: ${var.cloudflare_email}" \ -H "X-Auth-Key: ${var.cloudflare_token}" \ -H "Content-Type: application/json" \ --data '{"enabled":false}' EOH } }

Firewall Rules

resource "cloudflare_filter" "blacklist_ip" { zone_id = "${cloudflare_zone.zone.id}" description = "Block traffic from specific IPs" expression = "(ip.src eq some ips here)" }

resource "cloudflare_firewall_rule" "blacklist_ip" { zone_id = "${cloudflare_zone.zone.id}" description = "Block traffic from specific IPs" filter_id = cloudflare_filter.blacklist_ip.id action = "block" }

resource "cloudflare_filter" "block_empty_user_agents" { zone_id = "${cloudflare_zone.zone.id}" description = "Block empty user agents" expression = "(some stuff here)" }

resource "cloudflare_firewall_rule" "block_empty_user_agents" { zone_id = "${cloudflare_zone.zone.id}" description = "Block empty user agents" filter_id = cloudflare_filter.block_empty_user_agents.id action = "block" }

Sets the script with the name "script_1"

resource "cloudflare_worker_script" "my_script" { name = "REDACTED" content = file("file.js") }

Runs the specified worker script for all URLs that match

resource "cloudflare_worker_route" "my_route" { zone_id = "${cloudflare_zone.zone.id}" pattern = "${var.zone}/*" script_name = cloudflare_worker_script.my_script.name }

resource "cloudflare_worker_route" "sites_route" { zone_id = "${cloudflare_zone.zone.id}" pattern = "${var.zone}/failover/*" script_name = "REDACTED" }

Enable Argo Tiered Caching

resource "cloudflare_argo" "argo" { zone_id = "${cloudflare_zone.zone.id}" tiered_caching = "on" smart_routing = "off" }

[jacobbednarz]

Looks like the resource has an assumption that if you're using one of these features, you have entitlements to both.

https://github.com/terraform-providers/terraform-provider-cloudflare/blob/a522de34d92a728d938f63a4c1388a1c728b032f/cloudflare/resource_cloudflare_argo.go#L73-L92

I'm not sure if this was always the case but I'm happy to take a look at splitting this assumption to only impact the one being managed.

[jacobbednarz]

@stractenberg-newell Are you able to please pull #703 locally, build it (per the README instructions) and confirm it solves your issue? There is added test coverage for this use case but given it's a new case, I'd like to manually confirm too.