No tags are update after dashboard creation. Removing or adding tags, creates terraform changes but applying them has no effect on the dashboard.

Option missing to disable chart from being graphed. Useful for multiple queries used for calculations.

how are you escaping wildcards? i tried ${urlencode("*")} with no luck.

parameter_type only support SIMPLE and not LIST or DYNAMIC?

Need to be able to create different types of graphs other than the default type ( line )

Similar to other issue with multiple parameter details, multiple tags occasionally confuses terraform plan into thinking there are changes. The order of tags returned do not always match the original order of the terraform configuration.

~ module.test.wavefront_alert.Alert
tags.0: "test.tag0" => "test.tag2"
tags.1: "test.tag1" => "test.tag0"
tags.2: "test.tag2" => "test.tag1"

Running terraform plan a few times will sometimes return no changes.
This may also happen with dashboards but I haven't encountered it yet.

I have defult_time_window and custom height factor enabled on my dashboards. It's currently not supported so it always gets set to false upon terraform apply.

I've tested it using both Terraform 0.10.4 and 0.10.7.

It seems when I run terraform plan over a bunch of wavefront_alert resources, while they are planning, when I hit ctrl-c, it seems the provider (or Terraform) does not properly process my SIGINT, and just ignores it?

# ~/.tfenv/versions/0.10.7/terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

wavefront_alert.1479532300516: Refreshing state... (ID: 1479532300516)
wavefront_alert.1458021008243: Refreshing state... (ID: 1458021008243)
wavefront_alert.1494981712804: Refreshing state... (ID: 1494981712804)
wavefront_alert.1490742370268: Refreshing state... (ID: 1490742370268)
wavefront_alert.1487142060104: Refreshing state... (ID: 1487142060104)
wavefront_alert.1487802465744: Refreshing state... (ID: 1487802465744)
wavefront_alert.1460519330366: Refreshing state... (ID: 1460519330366)
wavefront_alert.1496692474344: Refreshing state... (ID: 1496692474344)
wavefront_alert.1506670630752: Refreshing state... (ID: 1506670630752)
wavefront_alert.1478203763652: Refreshing state... (ID: 1478203763652)
^Cwavefront_alert.1506054359125: Refreshing state... (ID: 1506054359125)
wavefront_alert.1492125056685: Refreshing state... (ID: 1492125056685)
wavefront_alert.1488961531031: Refreshing state... (ID: 1488961531031)
.
.
.

OTOH, I tested the same, using same Terraform, over some AWS resources, and Terraform does interrupt appropriately:

› /usr/local/Cellar/tfenv/0.5.2/versions/0.10.7/terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

aws_vpc.vpc: Refreshing state... (ID: vpc-8f7712e9)
aws_security_group.allow_all_outbound: Refreshing state... (ID: sg-7fa24d02)
aws_internet_gateway.igw: Refreshing state... (ID: igw-478bf120)
aws_subnet.public: Refreshing state... (ID: subnet-15bcc54e)
aws_route_table.rt: Refreshing state... (ID: rtb-dfd91fa6)
aws_route_table_association.rta: Refreshing state... (ID: rtbassoc-8d028df5)
aws_main_route_table_association.mrta: Refreshing state... (ID: rtbassoc-eb028d93)
^C
------------------------------------------------------------------------

No changes. Infrastructure is up-to-date.

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, no
actions need to be performed.

This may not be a bug, but is there anything a provider needs to do to process a ctrl-c?

TIA

Version: 1.0.2, I noticed a change in behavior from 1.0.1. Also Terraform v0.10.7 (but shouldn't matter).

With 1.0.1, if I have a Terraform managed (and applied) alert wavefront_alert.foo, if I deleted this WF alert manually using WF's web gui, the next time when I use Terraform to plan this alert, since my .tf file still contains its definition, Terraform plan tells me that it wants to create this alert as new:

+ wavefront_alert.foo

My course of action in this case is, to remove such alert definition from the .tf file.

With 1.0.2, the same workflow, but I can't even plan successfully, but with the following error:

wavefront_alert.foo: Refreshing state... (ID: 1234567890)
Error refreshing state: 1 error(s) occurred:

* wavefront_alert.1234567890: wavefront_alert.1234567890: Error finding Wavefront Alert . server returned 404 Not Found
{"status":{"result":"ERROR","message":"Alert 1234567890 does not exist","code":404}}

... and even after I remove its .tf definition, my terraform plan still errors out. At this point, I cannot terraform plan -destroy -target=wavefront_alert.foo (will fail with 404). I now have to resort to terraform state rm which is extremely unpleasant.

I think PR #27 is causing this behavior change to happen. I also think the former 1.0.1 behavior is more Terraform-esque from all the providers I've worked with. Do you agree?

... but it is marked as required in Terraform.

Using this JSON body, I managed to successfully create an alert in their "Try it out!" button without it:

{
  "name": "Alert Name",
  "target": "[email protected]",
  "condition": "ts(~sample.cpu.loadavg.1m) > 1",
  "displayExpression": "ts(~sample.cpu.loadavg.1m)",
  "minutes": 5,
  "severity": "INFO"
}

Hi,

I would like add a feature which takes JSON file as an input and create a dashboard. This will be really useful in adding existing dashboards from wavefront. Also wavefront has a feature where you can extract the JSON content and create a dashboard out of it.

Sample Terraform File

resource "wavefront_dashboard_json" "test_dashboard" {
  dashboard_json = file("${path.module}/test_dashboard.json")
}

or

resource "wavefront_dashboard_json" "json_foobar" {
	dashboard_json = <<EOF
{
  "name": "Terraform Test Dashboard",
  "description": "a",
  "eventFilterType": "BYCHART",
  "eventQuery": "",
  "url": "tftestimport",
  "displayDescription": false,
  "displaySectionTableOfContents": true,
  "displayQueryParameters": false,
  "sections": []
...
...
}
EOF
}

I have this feature working and I'm in process of adding tests. If you guys are fine with this feature, I will create a PR from my fork when it is ready.

Terraform's strings.TrimSpace will remove whitespace before and after a given string. I would like to propose to use it on the following Wavefront Alert fields that can get big and be implemented in heredocs:

condition
displayExpression
additionalInformation

Trimming the whitespace will make it consistent with the web values too. For example, with the following applied config:

resource "wavefront_alert" "foo" {
  condition = <<-EOS
    ts(stats.gauges.c4-2xl-spot-price) > 0.3
    EOS

  display_expression = <<-EOS
    ts(stats.gauges.c4-2xl-spot-price)
    EOS

... when I go to the web UI and just hit "Save" with non change, the condition and display_expression textboxes show no newline at the end of course, but a subsequent plan shows the following now:

  ~ wavefront_alert.foo
      condition:          "ts(stats.gauges.c4-2xl-spot-price) > 0.3" => "ts(stats.gauges.c4-2xl-spot-price) > 0.3\n"
      display_expression: "ts(stats.gauges.c4-2xl-spot-price)" => "ts(stats.gauges.c4-2xl-spot-price)\n"

      <web saved value> => HCL config heredoc value

... because the web saved value has no newline, but my heredoc has.

This request is motivated by a similar code change in the Datadog Provider, where their message field defines the rendering of an alert.

I haven't started creating other Wavefront objects in this plugin yet, but I am sure some other fields can also benefit from this feature request.

I am using go 1.11.5

$ go version
go version go1.11.5 linux/amd64

Unable to build terraform-provider-wavefront_v1.2.0_linux_amd64, below is the output:

$ git clone https://github.com/spaceapegames/terraform-provider-wavefront.git
Cloning into 'terraform-provider-wavefront'...
remote: Enumerating objects: 15, done.
remote: Counting objects: 100% (15/15), done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 1040 (delta 1), reused 9 (delta 1), pack-reused 1025
Receiving objects: 100% (1040/1040), 1.06 MiB | 425.00 KiB/s, done.
Resolving deltas: 100% (198/198), done.

$ cd terraform-provider-wavefront

$ ./build.sh
building terraform-provider-wavefront_v1.2.0_linux_amd64...
# _/tmp/tfwf/terraform-provider-wavefront
./main.go:10:3: cannot use wavefront_plugin.Provider (type func() "github.com/spaceapegames/terraform-provider-wavefront/vendor/github.com/hashicorp/terraform/terraform".ResourceProvider) as type "github.com/hashicorp/terraform/plugin".ProviderFunc in field value
building terraform-provider-wavefront_v1.2.0_darwin_amd64...
# _/tmp/tfwf/terraform-provider-wavefront
./main.go:10:3: cannot use wavefront_plugin.Provider (type func() "github.com/spaceapegames/terraform-provider-wavefront/vendor/github.com/hashicorp/terraform/terraform".ResourceProvider) as type "github.com/hashicorp/terraform/plugin".ProviderFunc in field value

Maybe it's just my use case, but I have display_query_parameters enabled on my dashboards. It's currently not supported so it always gets set to false upon terraform apply.

I am trying to use this provider behind a proxy and it does not appear to respect the HTTPS_PROXY environment variable.

Can you look into this?

I created an alert. terraform plan, terraform apply. Alert gets created. With no changes to config, terraform plan. It says it's refreshing the ID of the alert (ID matches correctly). terraform plan output is to create a new alert again. terraform apply will create a new alert with a new ID, resulting in a duplicate alert.

terraform destroy returns nothing to be destroyed but if I enter yes, the state is destroyed but the alerts still remain in wavefront.

using terraform v0.11.3

With latest release, values_to_readable strings now supports LIST type. After I apply, it works properly. Then terraform plan (with no modifications) incorrectly reads back the state and thinks it should apply and make changes.

There is an issue with the wavefront API when applying tagged alerts that it will cause a race condition. They are working on fixing this.

Do you know whether this has been fixed by Wavefront or not yet? Do you happen to have a ticket/issue number opened with them that I can have?

Occasionally I am getting Error finding Wavefront Alert errors:

wavefront_alert.1498186013614: Refreshing state... (ID: 1498186013614)
wavefront_alert.1494626662446: Refreshing state... (ID: 1494626662446)
wavefront_alert.1475626739625: Refreshing state... (ID: 1475626739625)
Error refreshing state: 11 error(s) occurred:

* wavefront_alert.1489083522148: 1 error(s) occurred:

* wavefront_alert.1489083522148: wavefront_alert.1489083522148: Error finding Wavefront Alert 1489083522148. Post https://metrics.wavefront.com/api/v2/search/alert: http: server closed idle connection
* wavefront_alert.1509396643007: 1 error(s) occurred:

* wavefront_alert.1509396643007: wavefront_alert.1509396643007: Error finding Wavefront Alert 1509396643007. Post https://metrics.wavefront.com/api/v2/search/alert: http: server closed idle connection
* wavefront_alert.1487887261795: 1 error(s) occurred:

* wavefront_alert.1487887261795: wavefront_alert.1487887261795: Error finding Wavefront Alert 1487887261795. Post https://metrics.wavefront.com/api/v2/search/alert: http: server closed idle connection
* wavefront_alert.1458691979355: 1 error(s) occurred:

Is it the case the WF's search API is not that reliable? Or is it that the alerts.Find() here is not waiting enough for results to be returned?

Is there any way to maybe turn on "debug" on these request/response made by the provider, so I can see more information?

Thanks!

When you specify one alert target the provider works fine:

resource "wavefront_alert" "test-alert" {
  name = "Test Alert"
  target = "webhook:k45j38gnk3l48in4"
  condition = "ts(heapster.pod_container.restart_count) > 20"
  display_expression = "ts(heapster.pod_container.restart_count) > 20"
  minutes = 10
  resolve_after_minutes = 5
  severity = "SEVERE"
  tags = [
    "sample"
  ]
}

But if try to specify more than one you get following error:

target = ["webhook:k45j38gn48in4","webhook:k4nhl3t834n34"]
Error: wavefront_alert.test-alert: target must be a single value, not a list
Error: wavefront_alert.test-alert target must be a single value, not a map

This should be supported since it can be done via wavefront.com

We'd like the ability to make the display of dashboard query params configurable.

Currently the provider only supports type=CLASSIC alerts.
This issue is about adding support for type=THRESHOLD alerts, which allow us to set different thresholds for different levels of severity in a single alert instance.
https://docs.wavefront.com/alerts.html#creating-a-multi-threshold-alert

Will likely need changes to https://github.com/spaceapegames/go-wavefront as well to enable this.

isHtmlContent is an option in Email Alert Targets to add HTML boilerplate to the Email content. This option is by default disabled.