feat: Allow a more flexible module extension. #368
+3
−3
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Allows using conditionals when extending this module to enable/disable features (replication, logging, inventory)
Motivation and Context
Basically we've been experiencing the same issue as the person in the aforementioned issue. We extend this module and need to enable/disable replication, logging and inventory using feature flags/variables.
This cannot be done in a single central child module (the one linked to this PR would be the parent), given that'd require a conditional with one side being a properly structured map and the other side being an empty map, which terraform doesn't seem to allow.
Impact : One option today for users is to deploy infrastructure for replication, logging and inventory, even if they don't need it. The other option is having N child modules on user side, for all combinations of (replication, logging, inventory).
Solution : Allowing those configurations to be nullable, does not break backward compatibility but enable users to have a single extended/child module that can be controlled via feature flags.
What does not work today :
What works thanks to this PR:
Breaking Changes
How Has This Been Tested?
examples/*to demonstrate and validate my change(s)examples/*projectspre-commit run -aon my pull request