Terraform-provider-newrelic: violation_close_timer attribute of newrelic_infra_alert_condition resource does not work for zero value

[samjgalbraith]

Terraform Version

Terraform v0.12.20

• provider.archive v1.3.0
• provider.aws v2.47.0
• provider.dns v2.2.0
• provider.newrelic v1.17.1
• provider.null v2.1.2

Affected Resource(s)

Please list the resources as a list, for example:

• newrelic_infra_alert_condition

Terraform Configuration Files

resource "newrelic_infra_alert_condition" "elasticsearch_snapshot_failure" {
    policy_id = var.new_relic_alert_policy_id
    name = "ES Cluster ${var.cluster_name} Backup Snapshot Failed"
    type = "infra_metric"
    event = "DatastoreSample"
    integration_provider = "ElasticsearchCluster"
    select = "provider.AutomatedSnapshotFailure.Maximum"
    where = "awsAccountId = '${data.aws_caller_identity.current.account_id}' AND provider.domainName = '${var.cluster_name}'"
    comparison = "above"

    critical {
        duration = 5
        time_function = "any"
        value = 0
    }
    violation_close_timer = 0
}

Expected Behavior

When violation close_timer is set to zero, the alarm condition is configured to disable timed violation closure for that alarm condition.

Actual Behavior

Timed violation closure is still enabled for the resource, with the default value (24). Successive Terraform apply attempts show that the desired state of this attribute does not match the observed state, but apply has no effect in resolving the difference.

Steps to Reproduce

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

1. terraform apply

[zlesnr]

Thanks for raising the issue. I've got a test that reproduces the issue you're pointing out. The API docs look a little sparse with respect to the violation_close_timer attribute, so I'll reach out to the infrastructure team for more detail.

[zlesnr]

Never-mind about the docs, this had nothing to do with the API. I've put up https://github.com/terraform-providers/terraform-provider-newrelic/pull/556 to resolve this.

[ctrombley]

@samjgalbraith This has been fixed in v1.18.0 of the provider. Give it a try and let us know if you have any issues.