Backport of Give suggestions & remind users to use required_providers when provider not in registry into v0.15 #28054
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.
Backport
This PR is auto-generated from #28014 to be assessed for backporting due to the inclusion of the label 0.15-backport.
The below text is copied from the body of the original PR.
When a user has any module, or child module, that has a
ErrRegistryProviderNotKnown
error, users are often confused why they don't get inheritance from other modules.Because Terraform explicitly loads modules as units with their own provider requirements (
required_providers
), and adds a suggestion of a provider "did you mean" if they have a provider of the same type (but not the default namespace) in their requirements.This is what the new suggestion looks like in practice (with suggestion):
This is what the new suggestion looks like in practice (without suggestion/no existing provider requirements):
Open to comments on improving this suggestion to be more user-friendly (for lack of a better term)
My hope is that this can address the (very valid!) concerns and comments surrounding issues like #27920 and #27701 . In #27920, Martin suggests an improvement where we could suggest a similar-name provider we may know about, but because of how the code is currently structured, I don't have confidence in picking an accurate (successful) name, so I am suggesting a more general suggestion here.
Fixes #27920
Fixes #27701