terraform-provider-cloudflare: Incorrect validation of alert_type in notification policy

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.2.4
on darwin_amd64
+ provider bitbucket.org/easybrain/godaddy v2.0.1
+ provider registry.terraform.io/cloudflare/cloudflare v3.18.0
+ provider registry.terraform.io/grafana/grafana v1.24.0
+ provider registry.terraform.io/hashicorp/aws v4.21.0
+ provider registry.terraform.io/hashicorp/vault v3.7.0
+ provider registry.terraform.io/ibm-cloud/ibm v1.43.0
+ provider registry.terraform.io/phillbaker/elasticsearch v2.0.2

Affected resource(s)

cloudflare_notification_policy

Terraform configuration files

resource "cloudflare_notification_policy" "example_notifications" {
  account_id  = "<<REDACTED>>"
  name        = "Expiring Service Token Alert"
  description = "Cloudflare Access service token expiration notice, sent 7 days before token is set to expire"
  alert_type  = "expiring_service_token_alert"
  enabled     = true

  webhooks_integration {
    ...
  }
}

Debug output

too many sensitive information

Panic output

No response

Expected output

Acquiring state lock. This may take a few moments...
...
Releasing state lock. This may take a few moments...

Actual output

Acquiring state lock. This may take a few moments...
...
╷
│ Error: expected alert_type to be one of [billing_usage_alert health_check_status_notification g6_pool_toggle_alert real_origin_monitoring universal_ssl_event_type bgp_hijack_notification http_alert_origin_error workers_alert weekly_account_overview], got expiring_service_token_alert
│ 
│   with module.cloudflare.cloudflare_notification_policy.easybrain_notifications["Expiring Service Token Alert"],
│   on modules/cloudflare/easybrain.tf line 225, in resource "cloudflare_notification_policy" "easybrain_notifications":
│  225:   alert_type  = lookup(each.value, "alert_type", null)
│ 
╵
╷
│ Error: expected alert_type to be one of [billing_usage_alert health_check_status_notification g6_pool_toggle_alert real_origin_monitoring universal_ssl_event_type bgp_hijack_notification http_alert_origin_error workers_alert weekly_account_overview], got dos_attack_l7
│ 
│   with module.cloudflare.cloudflare_notification_policy.easybrain_notifications["HTTP DDoS Attack Alert"],
│   on modules/cloudflare/easybrain.tf line 225, in resource "cloudflare_notification_policy" "easybrain_notifications":
│  225:   alert_type  = lookup(each.value, "alert_type", null)
│ 
╵
╷
│ Error: expected alert_type to be one of [billing_usage_alert health_check_status_notification g6_pool_toggle_alert real_origin_monitoring universal_ssl_event_type bgp_hijack_notification http_alert_origin_error workers_alert weekly_account_overview], got g6_health_alert
│ 
│   with module.cloudflare.cloudflare_notification_policy.easybrain_notifications["Load Balancing Health Alert"],
│   on modules/cloudflare/easybrain.tf line 225, in resource "cloudflare_notification_policy" "easybrain_notifications":
│  225:   alert_type  = lookup(each.value, "alert_type", null)
│ 
╵
╷
│ Error: expected alert_type to be one of [billing_usage_alert health_check_status_notification g6_pool_toggle_alert real_origin_monitoring universal_ssl_event_type bgp_hijack_notification http_alert_origin_error workers_alert weekly_account_overview], got dedicated_ssl_certificate_event_type
│ 
│   with module.cloudflare.cloudflare_notification_policy.easybrain_notifications["Dedicated SSL Alert"],
│   on modules/cloudflare/easybrain.tf line 225, in resource "cloudflare_notification_policy" "easybrain_notifications":
│  225:   alert_type  = lookup(each.value, "alert_type", null)
│ 
╵
Releasing state lock. This may take a few moments...

Steps to reproduce

Create cloudflare_notification_policy with non-supported by provider (since 3.18.0), but correct alert_type, for example expiring_service_token_alert

Additional factoids

Not each Cloudflare account has a list of alert types exactly the same you’ve introduced in the commit below.

References

https://github.com/cloudflare/terraform-provider-cloudflare/commit/c424ccdfd132d9eb7e50c201cfd6867a82198bfe

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 15 (4 by maintainers)

Most upvoted comments

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.

This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

github-actions[bot] on Jul 4, 2022

for functionality to be added to the provider (and other SDKs), it needs to be publicly documented and considered stable by the service team. no public documentation means there is no definition of the expected values and endpoints. there are plenty of APIs at Cloudflare and not all of them are intended or ready for public consumption.

@jacobbednarz Can we see where billing_usage_alert, health_check_status_notification, g6_pool_toggle_alert, real_origin_monitoring, universal_ssl_event_type, bgp_hijack_notification, http_alert_origin_error, workers_alert, weekly_account_overview are documented?

Cloudflare documents a list of available notifications: https://developers.cloudflare.com/fundamentals/notifications/notification-available/ which is also configurable in the admin panel. So these features are used by people in production environments, then why can’t we use these notification settings in terraform?

billxinli on Jul 18, 2022

Can we get a flag we can set to disable the forced validation added in 3.18?

zestysoft on Jul 13, 2022