[layers v2] Input/Output variable remapping for components and layers
- Dominant language
- Go
- Stars
- 569
- Forks
- 364
- Avg merge
- 2d 19h
- Merged PRs (30d)
- 136
Description
Part of #9765.
Design how components (layers, services, infra) handle inputs and outputs.
Now that we're importing modules and templates, we'll need a way to properly map inputs and outputs. Without this, imported components can collide on outputs, which is a fatal error in provisioning, or they'll consume the same inputs, which might be unintentional.
Here's an example of colliding outputs:
```yaml
# (old)
# using the same component - variables overlap
layers:
- name: database
infra:
# here we're using the same avm, twice, which means both instances will have the same input variables (ie, can't configure them
# independently), and the same OUTPUT variables (fatal error, today)
- name: cosmos-db-1
provider: avm
path: br/public:avm/res/service-bus/namespace:0.17.0
- name: cosmos-db-2
provider: avm
path: br/public:avm/res/service-bus/namespace:0.17.0
```
To fix this we can allow components (services, infra, and layers) to control naming for input and output variables:
```yaml
# (new)
# using the same component - handle output variables overlapping
layers:
- name: database
infra:
# here we're using the same avm, twice, which means both instances will have the same input variables (ie, can't configure them
# independently), and the same OUTPUT variables (fatal error, today)
- name: servicebus-1
provider: avm
path: br/public:avm/res/service-bus/namespace:0.17.0
outputs:
SERVICEBUS_1_NAME: NAME
- name: servicebus-2
provider: avm
path: br/public:avm/res/service-bus/namespace:0.17.0
outputs:
SERVICEBUS_2_NAME: NAME
```
Some questions:
- Do we want output mappings to be an all-or-nothing approach? If we do, that's simple enough. If we *don't* we need a way to know which outputs to exclude.
- Would we prefer just universally adding an OUTPUT_PREFIX, rather than specifying each variable explicitly?
- Some components (services) don't have outputs, and they might already have ways to handle inputs. Perhaps there's prior art we should lean on there so things feel consistent.
- Do we believe that output/input remapping should exist at all levels, or just at some?
Contributor guide
Assessment
This issue has not been assessed yet.