[AVM Question/Feedback]: base provider AzAPI instead of AzureRM

[Hi-Fi]

Check for previous/existing GitHub issues

• I have checked for previous/existing GitHub issues

Description

This is more of common for all AVM modules, but we have lately seen quite a lot of issues with AzureRM when working with private endpoint. Many AzureRM resources try in creation time to access to dataplane, which then causes failures and strange things.

Not sure if it's considered, but should AVM modules rely more on AzAPI instead of AzureRM? This would also be beneficial if thinking of Bicep AVM modules, as then it's easy to see that both are at the same level and do same things.

Things related to AzureRM issues that have also come with AVM modules

• Plan and apply for Key Vault takes over 5 minute when KV is using private connection that's not available from plan/apply runner. hashicorp/terraform-provider-azurerm#27067
• Cannot create azurerm_storage_container in azurerm_storage_account that uses network_rules hashicorp/terraform-provider-azurerm#2977
• [AVM Module Issue]: Use Azapi provider to create Container App environment terraform-azurerm-avm-ptn-cicd-agents-and-runners#50 (points to multiple AzureRM issues)

[matt-FFFFFF]

Hi!

I think the decision on the provider should be made by the module author. AzAPI v2.0 will be my preferred Azure provider due to the number of features making it into the next release.

How do you think we should handle the significant breaking change?

• Publish a new module?
• Manage using removed {} and import {} (removed could be in the module, but import would have to be external
• Other ideas?

[Hi-Fi]

In a way all the AVM modules have kind of issue that name contains "AzureRM" even they already use both. So in that sense new module would be clearer, or then statement that "Azurerm in name is not referring to AzureRM provider". But this case would be against Terraform's naming convention.

Of couse it would be nice to be able to just update version without any manual state handling, but on the other hand modules are still at 0 major version where every change can be breaking one by definition.

So, if name is not an issue an it's possible to do the update "behind the scenes" with just module version changes, that would be nicest. But as that would be against naming convention, maybe renaming would be the best. Of course the migration could still be offered with removed and import if possibe and robust enough.

[kewalaka]

Its partly an issue of discoverability. People searching for AzureRM module may overlook the azapi option, and honestly the internals of a module should not matter too much - rather whether the input & output specs suits the desired level of abstraction and the functionality it provides.

Modules suffer from bikeshedding - its easy to look inside and get nervous about the complexity, or whether it uses azapi or not. By contrast, far fewer people look inside the provider, or Terraform source code, but treat it as a building block to achieve an outcome. Another concern I have is by highlighting a difference it will amplify prejudices.

It's a shame the registry makes any distinction between the two - but given the current state, I lean more towards using the azurerm name.

Having two module implementations per resource (one based on azurerm the other on azapi), seems like a lot of work, and smells slightly of unfortunate compromise to me - not sure how best to bridge from an existing azurerm-based module to an azapi one in a way that won't annoy people & give chance for real use feedback.

This one is tricky.

[clarkbreyman]

@matt-FFFFFF - I'm curious in an upgrade scenario how existing state files would be upgraded without destroy and recreate, which could be operationally disruptive.

[kewalaka]

@clarkbreyman - not meaning to particularly promote this, but it saves me re-typing:

https://www.linkedin.com/pulse/terraform-move-from-azurerm-azapi-stu-mace-k8yuc/

basically the azapi provider supports using moved() to transfer from azurerm to azapi.

edit here's the official reference link - https://registry.terraform.io/providers/Azure/azapi/latest/docs/guides/feature_migrate_from_azurerm

[Hi-Fi]

Issue with moved probably is, that with HCL logic is (I think) quite impossible to do to offer both new and migration options. With e.g. CDKTF it's quite easy to support both scenarios as that logic is handled on CDK side first, and then synthesized HCL (JSON) either has or has not then specific block.

https://developer.hashicorp.com/terraform/language/moved for the moved block reference.

[matt-FFFFFF]

With the recent updates to azapi, supporting more data plane resources and adding support for migrating control plane keys and secrets we are looking to do this soon!