config: smarter provider alias usage validation #10807
Conversation
Fixes #4789 This improves the validation that valid provider aliases are used. Previously, we required that provider aliases be defined in every module they're used. This isn't correct because the alias may be used in a parent module and inherited. This removes that validation and creates the validation that a provider alias must be defined in the used module or _any parent_. This allows inheritance to work properly. We've always had this type of validation for aliases because we believe its a good UX tradeoff: typo-ing an alias is really painful, so we require declaration of alias usage. It may add a small burden to declare, but since relatively few aliases are used, it improves the scenario where a user fat-fingers an alias name.
|
It always felt to me like inheriting unaliased providers was a nice pragmatic decision to get the right behavior in the common case of "I have a bunch of modules with AWS stuff in them and I only want to configure this once". Inheriting aliased providers feels a little more dubious to me because it creates a hidden dependency from a child module to once of its ancestors which can't be seen in the variables and outputs, and there's no way to loosen that coupling because the I realize that this PR is about validating for the existing behavior rather than changing the behavior, so this comment is not really on topic... I guess it just never really occurred to me that alias providers were inherited too, since that felt kinda counter-intuitive. This comment is more "thinking aloud" than a specific objection to the change at hand... 😀 |
|
@apparentlymart I don't disagree, using a provider alias will limit the reusability of a module. Personally, I find it to be a relatively advanced feature and making inheritance available isn't such a bad thing. |
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
ghost
locked and limited conversation to collaborators
Fixes #4789
This improves the validation that valid provider aliases are used.
Previously, we required that provider aliases be defined in every module
they're used. This isn't correct because the alias may be used in a
parent module and inherited.
This removes that validation and creates the validation that a provider
alias must be defined in the used module or any parent. This allows
inheritance to work properly.
We've always had this type of validation for aliases because we believe
its a good UX tradeoff: typo-ing an alias is really painful, so we
require declaration of alias usage. It may add a small burden to
declare, but since relatively few aliases are used, it improves the
scenario where a user fat-fingers an alias name.