terraform-provider-opsgenie
terraform-provider-opsgenie copied to clipboard
Inconsistent ordering of members within opsgenie_teams
Terraform Version
Terraform v1.6.4
on darwin_amd64
+ provider registry.terraform.io/datadog/datadog v3.32.0
+ provider registry.terraform.io/hashicorp/archive v2.4.0
+ provider registry.terraform.io/hashicorp/aws v5.25.0
+ provider registry.terraform.io/hashicorp/null v3.2.1
+ provider registry.terraform.io/hashicorp/tfe v0.50.0
+ provider registry.terraform.io/integrations/github v5.42.0
+ provider registry.terraform.io/opsgenie/opsgenie v0.6.34
+ provider registry.terraform.io/sumologic/sumologic v2.27.0
Affected Resource(s)
- opsgenie_team
Terraform Configuration Files
resource "opsgenie_user" "first" {
username = "[email protected]"
full_name = "name "
role = "User"
}
resource "opsgenie_team" "test" {
name = "example"
description = "This team deals with all the things"
member {
id = "${opsgenie_user.first.id}"
}
Debug Output
N/A
Panic Output
N/A
Expected Behavior
Once the change has applied, no other changes will be detected as necessary without either the TF code changing or the config in OpsGenie changing.
Actual Behavior
Random drift:
- member {
- id = "This is the user's ID" -> null
- role = "user" -> null
- username = "[email protected]" -> null
}
+ member {
+ id = "This ID is 100% identical to the one being deleted"
+ role = "user"
+ username = Known after apply
}
Steps to Reproduce
terraform applyto apply the original configterraform planto see random/unexpected drift
Important Factoids
This appears to be a full regression of #326 and/or #288.
References
- GH-326
- GH-288
We are also experiencing this issue in provider version v0.6.34.
So, what I found as a workaround is if you also set the username attribute in the member block, that avoids the drift. Something with the username attribute being computed appears to be causing it to stay in a dirty state, even if neither the input nor output change between apply executions.