Issue using import with newrelic provider about terraform-provider-newrelic

[ss-remygreinhofer]

$ terraform --version
Terraform v0.11.10
+ provider.newrelic v1.2.0

We are using the newest version of terraform and the newrelic provider, but we are still facing the problem described in this issue.

Our policies and channels are correctly imported, but none of the conditions get linked to them. As a consequence, tf plan wants to recreate all of them.

[thejohnlin]

@ghstwhl
I ran into this issue recently and did some poking around.

I noticed you ran terraform import with what looks to be a policy ID.

If you take a look at the code beneath the covers, the provider is parsing the ID passed into terraform import and expecting two pieces: both the policy ID and the condition ID with a colon in the middle.

https://github.com/terraform-providers/terraform-provider-newrelic/blob/master/newrelic/resource_newrelic_alert_condition.go#L308

https://github.com/terraform-providers/terraform-provider-newrelic/blob/51875a56e41549e25dc74df484921412159bebf9/newrelic/helpers.go#L10

https://github.com/terraform-providers/terraform-provider-newrelic/blob/master/newrelic/resource_newrelic_alert_condition.go#L313-L314

If you import using <policy_id>:<condition_id>, you might see what I'm seeing now... which is a marshaling issue between float64 and string on the "threshold" field. The underlying alert_conditions API returns conditions given a policy ID.

[ashwin1dd]

Running into this as well. Has anyone been able to work around this?

[thejohnlin]

Running into this as well. Has anyone been able to work around this?

When I changed the type of the threshold field to be a string instead of float64, I was able to get it working.

[sanderblue]

@ghstwhl Apologies for a delay in response. We've recently focused more resources on maintaining the provider and in doing so, we've updated the Terraform provider to our new client, newrelic-client-go. In doing so, I have a hunch this might have been fixed as part of that update (or potentially as a result of other updates/fixes). I was unable to reproduce the primary reported problem with the current version of our provider, v1.12.2. I was also unable to reproduce the marshaling bug reported by @thejohnlin. Closing the issue since this looks to be resolved, but if anyone runs into any other issues please feel free to open new issue with your scenario.