Open Hi-Fi opened 3 weeks ago
matt-FFFFFF
commented
3 weeks ago 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?
removed {} and import {} (removed could be in the module, but import would have to be external
Hi-Fi
commented
3 weeks ago 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.
Check 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