Open franciscoescher opened 4 years ago
Hi @franciscoescher! Thanks for sharing this use-case.
Terraform currently supports the sort of abstraction you are looking to create via convention rather than by explicit interface as you showed here. The Multi-cloud Abstractions section of the Module Composition guide includes an example of a common interface for publishing DNS records that can be implemented by many different modules that target different DNS hosting vendors.
The Terraform language has a structural type system, which means it does type matching by the "shape" of the types rather than by their names. It's for that reason that it doesn't have any mechanism for giving custom names to types.
With that said, we'd hesitate to introduce a new concept like this for named types right now, but we'll leave this issue open in case you or others wish to share specific use-cases where you've tried the interface-by-convention approach described in the module composition guide and found it lacking in some way.
Thanks for the fast response! While I still think this kind of structure would be elegant as a solution, I understand the kind of design choices you guys need to make everyday. Will be looking forward to see the new features coming ahead :)
I'm still early into learning terraform but its been a repeated for me that there is no way to define a structural type "pattern" to help when passing data up and down between modules.
In one place I'm passing a top level variable down three layers and a response back up three layers. The presence of a mechanism by which i can say this is a foo_thing_config
and it will look a certain way, and that a variable input or module output will conform to that, would be a huge help in building simple, reusable modules. Particularly once validation stops being experimental, that would be a nice combination. Declaring specific types for validated combinations of simple types would be very handy for a lot of smaller parts.
Would it be possible to implement a 'module interface' (variables and outputs definitions) and to make a module variable type be one of these interfaces?
Among other things, this would be really useful for creating modules that do not depend on a specific cloud provider, for instance.
It would also allow a bigger abstraction when defining parameters as module inputs.
Example:
Interface definition
interface "app_interface" { variable "var1" {} output "out1" {} }
Another module var
variable "app" { type = interface.app_interface }