opsgenie / terraform-provider-opsgenie

Terraform OpsGenie provider
https://registry.terraform.io/providers/opsgenie/opsgenie/latest/docs
Mozilla Public License 2.0
106 stars 137 forks source link

Inconsistent ordering of members within opsgenie_teams #418

Open fishfacemcgee opened 11 months ago

fishfacemcgee commented 11 months ago

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)

Terraform Configuration Files

resource "opsgenie_user" "first" {
  username  = "test@domain.com"
  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 = "test@domain.com" -> null
}
+ member {
    + id = "This ID is 100% identical to the one being deleted"
    + role = "user"
    + username = Known after apply
}

Steps to Reproduce

  1. terraform apply to apply the original config
  2. terraform plan to see random/unexpected drift

Important Factoids

This appears to be a full regression of #326 and/or #288.

References

gustavlasko commented 2 months ago

We are also experiencing this issue in provider version v0.6.34.

fishfacemcgee commented 2 months ago

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.