Gain consistency about setting PolicyID on objects about newrelic-client-go HOT 4 CLOSED

Other alert condition types (all that I can tell) have PolicyID either in them or stitched in, so it seems reasonable to do so here as well.

from newrelic-client-go.

I think one use case and reason why PolicyID was stitched in to some struct was to facilitate terraform import for alert conditions, NRQL alert conditions, and plugins conditions.

Given the following HCL, it would be required to also have the alert policy defined as a separate block to import, but maybe someone didn't want to have both in their HCL.

resource "newrelic_alert_condition" "foo" {
  policy_id       = 123456
  name            = "foo"
  type            = "apm_app_metric"
  entities        = [654321]
  metric          = "apdex"
  condition_scope = "application"

  term {
    // ... 
  }
}

In order for terraform import newrelic_alert_condition.foo ... to work, since the API response for an alert channel doesn't contain a policy ID association anywhere, you would need to provide the policyID in some way. And since the Terraform read functionality doesn't have a way to read the policy_id directly from the HCL and policy_id does't exist in the state yet (hence the import), that's potentially one reason why it's stitched into the struct.

The stitched in PolicyID field is also used for create and is included in the return struct which is then used to create the ID hash of the resource.

If we removed PolicyID from the alerts.Condition struct, we would need to make sure we returned a tuple of the condition and the policy ID.

TL;DR It would appear that stitching the PolicyID might be a convenience thing vs a necessary thing, but the convenience factor seems to be pretty nice.

from newrelic-client-go.

We have consensus agreement that we should remove the transient PolicyID field from the following structs to facilitate a 1:1 mapping the associated API responses.

from newrelic-client-go.

Awesome. Good work here @sanderblue.

from newrelic-client-go.