Unexpected replacement plan of pingone_resource_attribute and pingone_schema_attribute

[kwri-avongluck]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

PingOne Terraform provider Version

0.11.1

Terraform Version

1.3.4

Affected Resource(s)

• pingone_resource_attribute

Terraform apply shows the following sudden drift (with no code or env changes):

  # pingone_resource_attribute.openid_preferredemail must be replaced
-/+ resource "pingone_resource_attribute" "openid_preferredemail" {
      ~ id               = "XXXX-XXXX-XXXX-XXXX-XXXX" -> (known after apply)
        name             = "email"
      ~ resource_id      = "XXXX-XXXX-XXXX-XXXX-XXXX" -> (known after apply) # forces replacement
      ~ type             = "PREDEFINED" -> (known after apply)
      + value            = "${user.ZZPreferredEmail}"
        # (3 unchanged attributes hidden)
    }

This throws:

�Terraform v1.3.4
on linux_amd64
pingone_resource_attribute.openid_preferredemail: Destroying... [id=XXXX-XXXX-XXXX-XXXX-XXXX]
╷
│ Error: Error when calling `DeleteResourceAttribute`: The request could not be completed. One or more validation errors were in the request.
│ 
│ PingOne Error Details:
│ ID: XXXX-XXXX-XXXX-XXXX-XXXX
│ Code: INVALID_DATA
│ Message: The request could not be completed. One or more validation errors
│ were in the request.
│ Details object: [{"code":"INVALID_VALUE","message":"PREDEFINED attributes
│ cannot be deleted.","target":"name"}]
╵
Operation failed: failed running terraform apply (exit 1)

Terraform Configuration Files

# https://github.com/pingidentity/terraform-provider-pingone/issues/318
data "pingone_resource" "openid" {
  environment_id = pingone_environment.agent_environment.id
  name = "openid"
}
.
.
resource "pingone_resource_attribute" "openid_preferredemail" {
  environment_id = pingone_environment.agent_environment.id
  resource_id    = data.pingone_resource.openid.id

  name = "email"
  value = "$${user.ZZPreferredEmail}"
}

Debug Output

Go Panic

None

Expected Behavior

Nothing

Actual Behavior

Failure on attempt to destroy resource.

Steps to Reproduce

1. terraform apply

Important Factoids

References

[kwri-avongluck]

@patrickcping FYI. This is related to #318

[patrickcping]

@kwri-avongluck Thanks for raising! This needs a full triage but I've been able to re-create the problem by making an upstream change to the pingone_environment (changing the description), that seems to force the pingone_resource data source to need a full refresh.

This also applies to the pingone_schema data source and the pingone_schema_attribute resource, which causes problems because as soon as user objects have defined values for that schema attribute, it cannot be replaced.

Until we can triage fully and issue a fix, you should be able to workaround using the lifecycle meta argument as follows:

resource "pingone_resource_attribute" "openid_preferredemail" {
  environment_id = pingone_environment.my_environment.id
  resource_id    = data.pingone_resource.openid.id

  name = "email"
  value = "$${user.ZZPreferredEmail}"

  lifecycle {
    ignore_changes = [
      resource_id,
    ]
  }
}

[patrickcping]

Created #331 to track the secondary issue that predefined OIDC resource attributes cannot be returned back to their default on destroy

[patrickcping]

Based on Hashicorp's documentation on Data Resource Dependencies this appears to be correct behaviour from a Terraform perspective.

We can look to solve this by changing the design of the provider, so (where possible) we remove the need for resources such as pingone_resource_attribute and pingone_schema_attribute to depend on data sources (to gain IDs) that in turn depend on the pingone_environment resource.

It is especially important that we do this for the pingone_schema_attribute resource to avoid accidental data loss.

We're working on a best practices guide that will document out measures to take to prevent accidental data loss, one of the points will be to use the prevent_destroy lifecycle meta argument on any pingone_schema_attribute resources that will be subject to production data.