Azure / Azure/Azure-Verified-Modules
[Feedback]: Inconsistent Provider Version Requirements Across Azure Verified Modules
- Dominant language
- PowerShell
- Stars
- 580
- Forks
- 161
- Avg merge
- 11h 3m
- Merged PRs (30d)
- 15
Description
### Check for previous/existing GitHub issues
- [x] I have checked for previous/existing GitHub issues
### Description
I am currently working on a project that leverages multiple Azure Verified Modules (AVMs), including:
- [Private DNS Zone Module](https://github.com/Azure/terraform-azurerm-avm-res-network-privatednszone/blob/main/terraform.tf)
- [Network Security Group Module](https://github.com/Azure/terraform-azurerm-avm-res-network-networksecuritygroup/blob/main/terraform.tf)
- [Route Table Module](https://github.com/Azure/terraform-azurerm-avm-res-network-routetable/blob/main/terraform.tf)
- [Virtual Network Module](https://github.com/Azure/terraform-azurerm-avm-res-network-virtualnetwork/blob/main/terraform.tf)
- [Storage Account Module](https://github.com/Azure/terraform-azurerm-avm-res-storage-storageaccount/blob/main/terraform.tf)
Each of these modules defines its own required versions for the `azurerm` and `azapi` providers, leading to version conflicts that prevent seamless integration within the same configuration and state.
Here’s a summary of the required provider versions across the modules:
| **Module** | **azurerm Provider** | **azapi Provider** |
|-----------------------------------|----------------------------------|------------------------------|
| **Private DNS Zone** | `>= 3.6, <= 3.114.0` | Not required |
| **Network Security Group** | `~> 3.71` | Not required |
| **Route Table** | `~> 4.0` | Not required |
| **Virtual Network** | `>= 3.0.0` | Not required |
| **Storage Account** | `>= 3.114.0, < 4.0.0` | `>= 1.14.0, < 2.0.0` |
This results in the following issues:
1. Version Conflicts: It is impossible to use all required modules together without encountering provider version mismatches, particularly with azurerm.
2. Module Interoperability Issues: Using multiple AVMs within the same Terraform configuration and state file becomes impractical. Splitting deployments into multiple state files adds unnecessary complexity and increases the configuration overhead for input/output management.
Suggested Improvements
To address these issues, I propose the following solution:
1. Standardize Provider Versions: The latest versions of all Azure Verified Modules should align with the same azurerm and azapi provider versions, or at least ensure cross-version compatibility for smoother integration.
If this alignment is not feasible, modules that require different provider versions to function should be explicitly marked as not solution compatible with others, helping users avoid potential issues.
By implementing these changes, the Azure Verified Modules will become significantly more user-friendly, enabling users to manage complex infrastructure deployments with less friction.
Thank you for considering this feedback. I hope this helps improve the AVM ecosystem.
This version simplifies the language while keeping the core points intact. It focuses on your proposed solution to standardize provider versions and adds the fallback suggestion for non-compatible modules. Let me know if this works!
Contributor guide
No contributing guide indexed for this repository
Research direction
Compare the terraform.tf files for the Private DNS Zone, Network Security Group, Route Table, Virtual Network, and Storage Account modules listed in the issue. Start by verifying their azurerm and azapi constraints, then determine whether a shared compatibility policy or explicit incompatibility marking is feasible. Done means the affected module requirements are aligned or documented as incompatible.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, terraform
- Domain
- cloud, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100