Known limitation: Cannot update the default computed parameter on resources, to set that resource as the default for an environment

[patrickcping]

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

Description

Some resources (listed below) have the ability to be set as default in a PingOne environment through a default parameter on the API. Those resources have the default attribute, but it is read-only (computed). Therefore it's not possible to set that resource as the default for the environment.

This has the consequence of not being able to update the configuration of the default instance of that resource, and it is left unmanaged by Terraform.

These resources are typically created by the platform bootstrap routine, and so their lifecycle is initially managed by the platform itself (or claimed by an out-of-band customer driven process), not this Terraform provider.

Request is to:

1. (Primary objective) bring these resources under lifecycle control of the Terraform provider
2. (Secondary objective) be able to change the value of the default parameter for a resource from true => false and false => true. This objective has a limitation as described below

New or Affected Resource(s)

• pingone_branding_theme (mitigated - see below)
• pingone_key
• pingone_language (mitigated - see below)
• pingone_mfa_fido_policy (deprecated)
• pingone_mfa_fido2_policy
• pingone_mfa_policy
  • Cannot set a default MFA Device Policy #382
• pingone_notification_policy
• pingone_population (mitigated - see below)
  • Known issue: Cannot configure the environment's default population when not using pingone_environment resource #462
• pingone_risk_policy
• pingone_sign_on_policy
  • Provide ability to set the default sign-on policy for an environment #394
• pingone_verify_policy

API Limitation on the default parameter

The API limitation is as follows:

• When default is configured false => true via a PUT request, it "claims" the default from the resource that previously had it. This has the potential to cause state inconsistency where the default value is stored in state as true for one resource, but is then changed by a different resource processed later in the apply phase. The platform will then be out of sync with the state.
• When default is configured true => false, this throws an API error, as it is expected that a different resource "claims" the default. There must be a different resource ready to be assigned the default = true value, and if configured in Terraform HCL, it must be guaranteed to run it's PUT API first.
  • If no other resource exists, this must be created and left unmanaged by Terraform. However if this is executed early in an apply phase and the intended resource is created later in the apply phase, this will leave redundant and unspecified (in HCL) configuration in the environment.
  • If another resource exists, it is not clear which should be assigned the default. Whichever is assigned the default may be subject to state inconsistency as described above.
  • When setting default from true => false in one resource, and setting default from false => true in another resource, a locked situation might arise whereby if the true => false is run first, the API error will abort the apply before the other resource is run. In this case, it would not be possible to change defaults between multiple resources of the same type. If this error is ignored, other changes in that environment would not take effect and would display inconsistent state errors as the end of the apply phase.

The expected mitigation of this limitation is a change to the API behaviour.

Tracked in STAGING-20045

Mitigated resources

The following resources have been mitigated as follows:

pingone_branding_theme (pingone_branding_theme_default)

The pingone_branding_theme resource has a dedicated API to be able to set and retrieve the default with and the provider implements the pingone_branding_theme_default that uses that API. This allows the admin to explicitly set the default without incurring the API limitation above.

pingone_language (pingone_language_update)

The pingone_language resource has the ability to overcome the API limitations by using the global default en language, which has a static in every customer environment, and by implementing the pingone_language_update resource. This allows the admin to explicitly set the default without incurring the API limitation above.

pingone_population (pingone_population_default)

The pingone_population_default resource is a variant of the pingone_population resource, and allows the admin to configure the default population for an environment, with the following behaviours:

• The default cannot be re-assigned to a different population resource. Once defined, the default cannot be changed through Terraform
• If the default population doesn't exist before pingone_population_default is created, the population will be created as normal.
• If a default population exists in an environment before pingone_population_default is created, the resource will assume control over the default population (assuming it is unmanaged)
• If a pingone_population_default resource is destroyed, the population will not be deleted from the PingOne service - it will instead be left in place and removed from Terraform management. This is because there is an API restriction such that there must be one default population for an environment, once one is created.
• Only one pingone_population_default resource should be configured per PingOne environment, as a PingOne environment can only have one default population.

[patrickcping]

@dbryar Referencing question raised here: #310 (comment)

Is there any update to the issues surrounding the inability to set defaults?

Not yet - we've had the confirmation that the ideal fix (changes to the API) are a heavier lift and not currently planned. I have a plan as to how to work around the conflicts described in this issue but it will take time to pull together. I'll update here as I know more