Convert Legacy Logical and Read-only Resources to Data Sources

[apparentlymart]

With the data resource concept now in master, we have the opportunity to convert a number of existing "data-resource-like" resources to be true data resources.

This is a roll-up issue to capture the list. The intent is not that they be attacked all in one step, but rather that we make several small PRs to convert them and then track the overall progress here.

The focus of this issue is existing resources to convert, not ideas for new data sources we might build. If I missed any, please let me know!

atlas provider (#7419):

• atlas_artifact can be converted straightforwardly using the "shim" in helper/schema

consul provider (#7678):

• consul_keys should be both a data resource (for reads) and a managed resource (for writes); key blocks without value on the consul_keys managed resource should generate a deprecation warning advising users to switch to the data resource.

docker provider (#7000):

• docker_image can potentially become a data resource but the separation of concerns between it and docker_container would need to change as discussed in Docker images version change do not trigger container update #3639.

template provider (#6717):

• template_file can be converted straightforwardly using the "shim" in helper/schema
• template_cloudinit_config can be converted straightforwardly using the "shim" in helper/schema

terraform provider:

• terraform_remote_state was converted using the "shim" in helper/schema as part of Data-driven Terraform Configuration #6598

tls provider (#7469):

• tls_cert_request can be converted straightforwardly using the "shim" in helper/schema

tls_private_key, tls_self_signed_cert and tls_locally_signed_cert must remain as managed logical resources, since they use the resource lifecycle even though their implementation exists entirely within Terraform.

[jen20]

In the case of docker_image this should probably only do the search, and leave the resource docker_image to actually pull that from the repository?

[apparentlymart]

@jen20, yeah, that's a good sum-up of the more long-winded way I said the same thing in #3639. 😀

Update: oh wait, not quite: my proposal was that docker_image the resource goes away altogether (after a deprecation cycle) and docker_container grows the ability to fill the local image cache. See that other ticket for the long-winded rationale.

[stack72]

@apparentlymart looks like we are all up to date on this one - closing as all parts are now merged :)

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.