hashicorp / hashicorp/terraform-plugin-sdk
Allow data source schema & CRUD to be inherited from resource
- Dominant language
- Go
- Stars
- 485
- Forks
- 244
- Avg merge
- 19h 57m
- Merged PRs (30d)
- 4
Description
Data sources are subset of resources in that `R` is subset of `CRUD`.
There may be cases when exposing resource as a data source may be impractical or useless, but in most cases data sources were implemented by leveraging existing `Read` method of existing resources, sometimes quite literally, sometimes with an addition of thin layer of code.
While this is technically possible today, it doesn't look nice due to the fact that almost the exact same schema has to be (re)written with `Computed: true` options for each data source.
There is still many valid use cases for standalone data sources (e.g. AWS AMIs which Terraform will ever unlikely "manage"), so that concept alone should certainly stick around, but it should be easier/cleaner to expose data sources by leveraging existing resources.
Relatedly each data source today requires its own separate set of acceptance tests despite having pretty much the same schema and implementation as its resource that already has tests.
It should therefore be easier to write acceptance tests for such data sources.
Contributor guide
Research direction
Start by comparing how existing resources and data sources define their schemas, reuse Read behavior, and implement acceptance tests. Determine a workable inheritance model that preserves standalone data sources and defines how shared acceptance coverage would work; done means the proposed API and testing approach are clear and validated against representative cases.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, terraform
- Domain
- api, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100