Treat notification as an object instead of a string about terraform-provider-signalform HOT 3 OPEN

This will require quite a bit of refactoring on our side, since we have countless detectors and a couple terraform modules relying on this being a string. @dichiarafrancesco is part of the team maintaining our internal repos, so any non-backward compatible change to the API must be approved by him or someone else on the Metrics Infra team.

Anyway, I think that your change makes sense; I don't know what's the reason why this was implemented as a string in the first place. Not sure which one of the two approaches you proposed is better, though. And team support for SignalFx is something we always had in our backlog, so that is definitely exciting!

from terraform-provider-signalform.

Will give it a look on Monday. I need sometime to plan the eventual shift from our current way to-do-things and the new one. hope it's not a big blocker for you.

from terraform-provider-signalform.

Would it be an acceptable workaround if, for the time being, we supported both? We could have notifications as the keyword for the list of strings, and notification as the keyword for the more thorough HCl description.

from terraform-provider-signalform.