After the default retention policy on a influxdb_database is created, it cannot be managed using this provider.
Terraform Version
$ terraform -v
Terraform v1.5.1
on darwin_amd64
+ provider registry.terraform.io/drfaust92/influxdb v1.6.1
Though this issue applies to any version of terraform and all versions of this provider so far.
Affected Resource(s)
Please list the resources as a list, for example:
Terraform Configuration Files
Create a database:
resource "influxdb_database" "test" {
name = "test"
}
Modify the retention policy, in this case updating the duration
resource "influxdb_database" "test" {
name = "test"
retention_policies {
name = "autogen"
duration = "24h0m0s"
default = "true"
shardgroupduration = "168h0m0s"
}
}
Expected Behavior
The existing retention policy should be updated to reflect the desired changes.
Actual Behavior
The DB retention policy is not modified, and there is perpetual drift after applies.
# influxdb_database.kube_images will be updated in-place
~ resource "influxdb_database" "test" {
id = "test"
name = "test"
+ retention_policies {
+ default = true
+ duration = "24h0m0s"
+ name = "autogen"
+ replication = 1
+ shardgroupduration = "168h0m0s"
}
}
Steps to Reproduce
terraform apply with the "Create a database" HCL above
terraform apply with the "Modify the retention policy" HCL above
Notes
I believe this issue is caused by the provider explicitly ignoring the default retention policy in the readRetentionPolicies method:
|
if reflect.DeepEqual(retentionPolicy, defaultRetentionPolicy) { |
|
continue |
|
} |
I noticed this when importing an existing influx database that had the default retention policy defined.
This behavior makes sense in the case when we want to create a database and have the default retention policy automatically created (and not tracked in terraform), but it causes issues when we want to modify that default retention policy down the road.
Perhaps we can add a boolean parameter to this method (ie ignoreDefaultRetentionPolicy), and set this to false when we detect a desired retention policy that has default = true and name = "autogen". I believe that would fix the issue and not cause breaking changes.
Workaround
It seems like currently, the only workaround is to manually modify the retention policy, such that the DeepEqual call fails. Modifying the retention or replication seems most viable.
Example workaround:
ALTER RETENTION POLICY autogen ON "database-name" REPLICATION 2
After the default retention policy on a
influxdb_databaseis created, it cannot be managed using this provider.Terraform Version
Though this issue applies to any version of terraform and all versions of this provider so far.
Affected Resource(s)
Please list the resources as a list, for example:
Terraform Configuration Files
Create a database:
Modify the retention policy, in this case updating the duration
Expected Behavior
The existing retention policy should be updated to reflect the desired changes.
Actual Behavior
The DB retention policy is not modified, and there is perpetual drift after applies.
Steps to Reproduce
terraform applywith the "Create a database" HCL aboveterraform applywith the "Modify the retention policy" HCL aboveNotes
I believe this issue is caused by the provider explicitly ignoring the default retention policy in the
readRetentionPoliciesmethod:terraform-provider-influxdb/influxdb/resource_database.go
Lines 208 to 210 in dd7445d
I noticed this when importing an existing influx database that had the default retention policy defined.
This behavior makes sense in the case when we want to create a database and have the default retention policy automatically created (and not tracked in terraform), but it causes issues when we want to modify that default retention policy down the road.
Perhaps we can add a boolean parameter to this method (ie
ignoreDefaultRetentionPolicy), and set this tofalsewhen we detect a desired retention policy that hasdefault = trueandname = "autogen". I believe that would fix the issue and not cause breaking changes.Workaround
It seems like currently, the only workaround is to manually modify the retention policy, such that the
DeepEqualcall fails. Modifying theretentionorreplicationseems most viable.Example workaround: