Azure / Azure/Azure-Verified-Modules

[Feedback]: Inconsistent Provider Version Requirements Across Azure Verified Modules

Open
#1,576 4 comments 1 reaction 0 assignees View on GitHub
Language: Terraform :globe_with_meridians: Needs: Core Team :genie: Status: In Triage :mag: Type: Question/Feedback :raising_hand:
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.