Consider deprecating the force_delete_production_type provider parameter in favour of a prevent_destroy on the pingone_environment resource

[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

To allow a better design pattern of per-resource destroy protection, the global provider parameter force_delete_production_type could be deprecated in favour of a prevent_destroy_production_type on the pingone_environment resource itself.

This way destroy protection can be applied per-environment, and may allow a better model for per-resource destroy protection and data delete protection going forward.

The prevent_destroy_production_type on the pingone_environment would default to true and the HCL writer would have to explicitly set the value to false to allow forceful destroy of a PRODUCTION environment.

Note that this parameter will behave in the same way as the current provider parameter force_delete_production_type in that it forcefully overrides the environment's in-built protection of environments of PRODUCTION type.

To do: consider a global method of resource protection that can be applied to any resource.

New or Affected Resource(s)

• pingone_environment

Potential Terraform Configuration

# Copy-paste your PingOne related Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key.

# Remember to replace any account/customer sensitive information in the configuration before submitting the issue
provider "pingone" {
}

resource "pingone_environment" "my_environment" {
  name        = "New Environment"
  description = "My new environment"
  type        = "PRODUCTION"
  license_id  = var.license_id

  default_population {
    name        = "My Population"
    description = "My new population for users"
  }

  service {
    type = "SSO"
  }

  service {
    type        = "PingFederate"
    console_url = "https://my-pingfederate-console.example.com/pingfederate"
  }

  prevent_destroy_production_type = false
}

References

[patrickcping]

Relates to #234

[samir-gandhi]

Can/Should we also consider a datasource for Population.
In some cases we may just want to use the default that is bootstrapped, but we need to read it to get the id.
So instead we are creating a population resource, which leads us to this situation

[patrickcping]

A population data source is a good idea, but I'd like to solve that bootstrapped population use case by resolving #135

Idea being, the default population on the environment resource actually uses the bootstrapped default population instead of creating it's own as it does now

[patrickcping]

Recommendation is to follow the documented best practice:

• Protect Configuration and Data with the lifecycle.prevent_destroy Meta Argument

Closing out with no further action