Common resource patterns #

Singletons #

Singletons are resources – often config or settings objects – that can only exist once. In some cases, it may be possible to create and delete the resource (but only one can exist at a time); in other cases the resource always exists and can only be read and updated.

Implementing resources like this may require some or all of the following:

If there isn’t a create endpoint, set the create_url to point to the update endpoint.
If there is a create endpoint, add pre-create custom code that implements “acquire-on-create” logic. The custom code should check whether the resource already exists with a read request, and if it does, run the update logic and return early. For example, see mmv1/templates/terraform/pre_create/firebasehosting_site.go.tmpl.
- Note: The main disadvantage of “acquire-on-create” logic is that users will not be presented with a diff between the resource’s old and new states – because from the terraform perspective, the resource is only being created. Please upvote https://github.com/hashicorp/terraform/issues/19017 to request better support for this workflow.
If there is no delete endpoint, set exclude_delete: true at the top level of the resource.

Tests for singletons can run into issues because they are modifying a shared state. To avoid the problems this can cause, ensure that the tests create dedicated parent resources instead of modifying the default test environment. If there need to be multiple test cases, make sure they either have individual parent resources, or that they run serially, like TestAccAccessContextManager.