It seem the provider doesnt understand RESAMPLE syntax. CQ creation is failing for the advanced cq syntax

Terraform Version

0.12

Affected Resource(s)

Please list the resources as a list, for example:

• influxdb_continuous_query

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

   resource "influxdb_continuous_query" "minnie" {
    name = "minnie"
    database = "${influxdb_database.test.name}"
    query = "RESAMPLE EVERY 5m FOR 10m  SELECT min(mouse) INTO min_mouse FROM zoo GROUP BY time(30m) end"
}

Debug Output

Please provider a link to a GitHub Gist containing the complete debug output: https://www.terraform.io/docs/internals/debugging.html. Please do NOT paste the debug output in the issue; just paste a link to the Gist.

Panic Output

If Terraform produced a panic, please provide a link to a GitHub Gist containing the output of the crash.log.

Error: error parsing query: found RESAMPLE, expected SELECT at line 1, char 112

### Expected Behavior
What should have happened?
Cq should have been created

### Actual Behavior
What actually happened?
no CQ created

### Steps to Reproduce
Please list the steps required to reproduce the issue, for example:
1. `terraform apply`

 

It is not currently possible to import existing databases, users, continuous queries and such into terraform, but it would be nice to.

After provisioning a few databases, user and grants for multiple databases, Terraform detects un-applied changes to reorder grants which makes no sense.

$ terraform plan
<...>
  ~ module.common.influxdb_user.grafana
      grant.0.database: "consul" => "telegraf"
      grant.1.database: "namerd" => "consul"
      grant.2.database: "telegraf" => "namerd"
      grant.4.database: "linkerd" => "nomad"
      grant.5.database: "nomad" => "linkerd"
<...>

Terraform Version

$ terraform -v
Terraform v0.11.7
+ provider.influxdb v1.0.0

Affected Resource(s)

• influxdb_user

Terraform Configuration Files

Any configuration with a user having multiple grants to different databases

Debug Output

https://gist.github.com/olgert/4ef79545603e6f4e806652904b8141fd

Panic Output

N/A

Expected Behavior

No changes to apply

Actual Behavior

Terraform tries to apply different ordering of grants

Steps to Reproduce

1. Have any configuration with a user having multiple grants to different databases
2. terraform apply
3. terraform plan

Important Factoids

N/A

References

N/A

This is enhancement request to support retention policies in influxdb_database resource. We are using InfluxDB for monitoring and for production usage we obviously need different retention policies set on different databases. In case of InfluxDB RPs (Retention Policies) are tied to InfluxDB Database so I am proposing having optional configuration in "influxdb_database" resource that'll allow us to also set RPs for that database. I've added sample configuration in following sections. Following attributes can be supported on retention_policy tag:

Name: Required attribute, Suggests a name for RP
Duration: Required attribute, Duration of RP
Replication: Optionale attribute, defaults to 1. Replication for RP.
Default: Optional attribute, defaults to false. Whether this RP is default RP or not.
ShardGroupDuration: Optional, defaults to auto determined by InfluxDB.

I've started working on getting this support coded, I've opened PL with these changes at #3

Terraform Version

Terraform v0.10.5

Affected Resource(s)

• influxdb_database

Terraform Configuration Files

resource "influxdb_database" "testdb" {
  name = "testdb"
  retention_policies = [
    {
      name = "1day",
      duration = "1d"
    },
    {
      name = "3weeks",
      duration = "3w"
    }
  ]
}

This is enhancement request to support subscriptions in InfluxDB provider. InfluxDB subscriptions are used to send data to Kapacitor (metrics stream processor) and data replication. The proposal is to include subscriptions definition as an optional field inside retention policy, because any subscription is bounded to specific database and retention policy.

Attributes:

• name: string, required, name of subscription;
• mode: string, required, either ALL or ANY;
• destinations: list of strings, required at least one element, destinations to write data to.

More on subscriptions syntax:
SHOW SUBSCRIPTIONS
CREATE SUBSCRIPTION
DROP SUBSCRIPTION

Terraform Version

Terraform v0.11.3

Affected Resource(s)

• influxdb_database

Terraform Configuration Files

resource "influxdb_database" "metrics_aggregation" {
  name = "testdb11"
  retention_policies = [
    {
      name = "52weeks",
      duration = "52w"
      default = "true"
      subscriptions = [
          {
              name = "sub0",
              mode = "ALL",
              destinations = [
                  "udp://h1.example.com:9090", 
                  "udp://h2.example.com:9090",
              ]
          },
      ]
    },
  ]
}

As part of the preparation for Terraform v0.12, we would like to migrate all providers to use Go Modules. We plan to continue checking dependencies into vendor/ to remain compatible with existing tooling/CI for a period of time, however go modules will be used for management. Go Modules is the official solution for the go programming language, we understand some providers might not want this change yet, however we encourage providers to begin looking towards the switch as this is how we will be managing all Go projects in the future. Would maintainers please react with 👍 for support, or 👎 if you wish to have this provider omitted from the first wave of pull requests. If your provider is in support, we would ask that you avoid merging any pull requests that mutate the dependencies while the Go Modules PR is open (in fact a total codefreeze would be even more helpful), otherwise we will need to close that PR and re-run go mod init. Once merged, dependencies can be added or updated as follows:

$ GO111MODULE=on go get github.com/some/module@master
$ GO111MODULE=on go mod tidy
$ GO111MODULE=on go mod vendor

GO111MODULE=on might be unnecessary depending on your environment, this example will fetch a module @ master and record it in your project's go.mod and go.sum files. It's a good idea to tidy up afterward and then copy the dependencies into vendor/. To remove dependencies from your project, simply remove all usage from your codebase and run:

$ GO111MODULE=on go mody tidy
$ GO111MODULE=on go mod vendor

Thank you sincerely for all your time, contributions, and cooperation!

Hi there,

I contact you because today I merged our infrastructure project to Influxdb v2 stable. We created two terraform providers, first for the onboarding and second to create resources like a bucket or an authorization. But when I want to create a bucket, with using the latest version of this go client, the influxdb api shows that the retention policy needs to be at least 1h.

Terraform Version

Terraform v0.13.1

Affected Resource(s)

Please list the resources as a list, for example:

• CreateBucket

Terraform Configuration Files

resource "influxdbv2_bucket" "forecasts" {
  depends_on = [influxdbv2-onboarding_setup.setup]
  name = "forecasts"
  org_id = influxdbv2-onboarding_setup.setup.org_id
  rp = "2h"
  retention_rules {
    every_seconds = 1
  }
}

I also tested the rp parameter with "1h0m0s". No difference.

Panic Output

internal error: retention policy duration must be at least 1h0m0s

Expected Behavior

The expected bahaviour should be the creation of the bucket resource in influxdb.

Actual Behavior

Error shown in the terminal.

So, is this due because the client has not been updated with the last Influxdb v2 release ? Or is it an error elsewhere ?

You can find our providers here:

• influxdbv2-onboarding : https://github.com/lancey-energy-storage/terraform-provider-influxdb-v2-onboarding
• influxdb : https://github.com/lancey-energy-storage/terraform-provider-influxdb-v2

As Influxdb v2 gets closer and closer to beta I'm wondering how to to approach the provider for that. I see 3 different options for this:

• Would it make sense to have a totally dirferent provider like github.com/terraform-providers/terraform-provider-influxdbV2
• To have both in parallel with a configuration that switch between the two like:

provider "influxdb" {
  url      = "http://influxdb.example.com/"
  organization = "terraform"
  influxdb_version = "2"
}

• or, my favourite, would be to have a "complete rewrite" in place cutting a new major release so people can use the Influxdb V1 provider by using the version = 1.3.0 of the provider and the version = 2.0.0 of the provider for the influxdb V2 server.

The influxdb Terraform provider attempts to sanity check and ping test the url value in the provider block. This is problematic when Terraform has even begun to provision a influxdb instance.

I think any checking/pinging should be delayed until the influxdb resources are run.

Terraform Version

Terraform v0.11.7

• provider.azurerm v1.11.0
• provider.grafana v1.0.2
• provider.influxdb v1.0.1
• provider.random v1.3.1

Affected Resource(s)

provider "influxdb"

Terraform Configuration Files

provider "influxdb" {
  url      = "http://${azurerm_container_group.hydra-loadtestdb-cg.ip_address}:8086"
  username = "admin"
  password = "${random_string.influx_admin_pass.result}"
}

Debug Output

https://gist.github.com/paulgrav/620793871695c4f8c6298beb36120730

Expected Behavior

Provider should not assume that an InfluxDB has already been provisioned. InfluxDB resources should begin provisioning once dependencies have completed.

Actual Behavior

Provider attempts to ping test an InfluxDB has has yet been provisioned. Terraform apply command fails.

Steps to Reproduce

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

1. terraform apply

Important Factoids

n/a

References

n/a

Terraform Version

Terraform v0.11.8

Affected Resource(s)

provider.influxdb: v1.0.1

Terraform Configuration Files

provider “influxdb” {
 url      = “https://<my_host>:8443”
 username = “admin”
}

Debug Output

Failure available at https://gist.github.com/schahal/4f4fd3efedd6c1bf7215ce4a3cb0c0c7

Expected Behavior

Since this is an InfluxDB instance with HTTPS-enabled and a self-signed cert (not a valid certificate authority), the terraform execution plan should still successfully display

Actual Behavior

What actually happens is that when we run terraform plan, we get the following complaint:

provider.influxdb: error pinging server: Get https://<myHost>:8443/ping: x509: certificate signed by unknown authority

And we're unable to continue.

Steps to Reproduce

1. Make sure you have a running InfluxDB server
2. Create a self-signed certificate (using openssl)
3. Update InfluxDB config to enable https and point the cert to path of (2)
4. Restart InfluxDB to make sure HTTPs is enabled
5. Using .tf config from above, run terraform apply

Important Factoids

N/A

References

N/A