Hi Team,
We have a few terraform modules that use multiple terraform providers (AWS & Snowflake), what’s the naming convention in such a situation?
Is there naming convention that will allow multiple providers to specified?
Examples:
Snowflake API Integration Module
Snowflake Storage Integration Module
Hi @sfc-gh-pkommini,
I think you are asking about the module registry package addressing scheme which includes a last part representing a “target system” that the module is intended for, and that Terraform Registry’s documentation and UI often refers to that component as a “provider” for modules published in that registry.
The truth is that this naming scheme is really just a convention for humans and so you can choose whatever “target system” name seems most intuitive for the module in question.
In this case this is subjective: is the main distinguishing thing about this module that it’s targeting AWS, or that it’s targeting Snowflake?
Since these modules seem to be provided by Snowflake Labs it seems like the family is likely to expand by offering different target systems to use Snowflake with rather than supporting similar Snowflake-like systems on AWS. If that’s true, then a naming scheme like the following would best match the intent of this “target system” address field:
snowflake-labs/snowflake-storage-integration/awssnowflake-labs/snowflake-api-integration/awssnowflake-labs/snowflake-storage-integration/azuresnowflake-labs/snowflake-api-integration/azuresnowflake-labs/snowflake-storage-integration/alicloudsnowflake-labs/snowflake-api-integration/alicloudThe connotation of the above is that the modules that have the same name but different target systems are somehow “functionally equivalent”, offering the same (or close enough) functionality for different underlying cloud platforms. Someone who wants to set up the same system design in both AWS and Azure would expect snowflake-labs/snowflake-storage-integration/aws and snowflake-labs/snowflake-storage-integration/azure to both be playing the same architectural role just with different implementation details.
I hope that’s helpful! Ultimately there are no technical restrictions on how you choose to name these, so if I have the wrong idea about what these addresses are meant to represent there is nothing to stop you from setting the target system name to snowflake and putting the underlying system name in the name field. It’s just a question of how you’d prefer users of the modules to imagine their relationships.