provider GenerateResourceConfig #37515
Conversation
71acb15 to
dbf4fe3
Compare
The Resource struct didn't really match the data structure. Refactor this to make it easier to break up the config generation calls so we can pass in final config from the provider.
Now that the refactoring is complete, we can actually call the provider to generate the config value. The schema fetching and method arguments are still a mess, but that was the case before too, and we can take time to clean up the call chain later.
dbf4fe3 to
97ebb6c
Compare
| State: state, | ||
| } | ||
|
|
||
| resp := provider.GenerateResourceConfig(req) |
There was a problem hiding this comment.
What if the provider includes values that should not be in config, e.g computed or sensitive attributes? Do we historically do a second validation check of providers' value manipulation, or can we rely on the plugin framework to have validated that?
There was a problem hiding this comment.
Oh yes, that validation just hasn't been written yet ;) We've always tended to double up on these validations, because the framework isn't technically required for providers. The provider developers want it in the framework so that testing can catch problems before actual integration.
|
@jbardin interesting move! What we would like to see is whenever we run a plan and terraform proposes resources to be created, to run an a cycle to validate whether the resources already exist. This should render a separate imports.tf which then can be amended. |
Core implementation of the
GenerateResourceConfigprotocol, allowing providers to create the instance configuration value when importing new resources.Most of the work here is refactoring the config generation code, to finish separating the HCL generation from the config generation, allowing Terraform to ask the provider to create the appropriate values rather than using internal heuristics. This does require another call for each and every resource instance, but because importing with config generation is not a primary workflow, the overall overhead is minimal.
The change adds two pieces to the protocol, a
GenerateResourceConfigRPC, and the accompanying flag inServerCapabilities. While it is a net new call which we can detect the existence of at runtime, because the call needs to be conditional in the core code it is more convenient to know ahead of time what the server capabilities are rather than creating a special error type for the internal interface. Using capabilities also gives the framework authors the more flexibility when implementing this for muxed providers, since they could update the protocol before finishing implementation.