The “provider” portion of the name is conventionally the name of the provider of the main remote system the module works with, but of course there are several situations where it’s not possible to follow that convention exactly:
- If a module exists to create a bridge between two remote systems, such as creating an VPN connection between two different vendor VPC implementations.
- If a module contains only local logic and doesn’t interact with any remote systems at all, as seems to be true in your case.
The good news is that there is no enforcement of the string you choose for “provider”, and it’s there primarily to help distinguish similarly-named modules targeting different providers, such as the modules in the
You can actually see in that
terraformdns set a module that has the same “problem” you’ve encountered:
terraformdns/dns-zonefile/template actually has no resources in it at all and instead does all its work with Terraform language expressions.
My sense is that there is an even less formal convention in the public registry to use a pseudo-provider name like
template (e.g. if a module consists mainly of string template operations) or
cidr (e.g. if a module consists mainly of calls to
cidrhost functions), where the chosen “provider name” is often the name a real provider whose scope of functionality is related to what the module does even if it isn’t actually using that provider directly.
In your private registry you have even more latitude to choose a convention that makes sense for you and your organization. For your situation where the module is mainly just home to a set of shared values that are used in many places, I might choose a pseudo-provider name like “any” or “generic” or similar, to try to communicate that this module is potentially applicable to configurations that target any remote system.