azurerm_automation_module can't import newer versions of default modules

[prubis]

Is there an existing issue for this?

• I have searched the existing issues

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

1.1.7

AzureRM Provider Version

2.95.0

Affected Resource(s)/Data Source(s)

azurerm_automation_module

Terraform Configuration Files

resource "azurerm_resource_group" "example" {
  name     = "example-resources"
  location = "West Europe"
}

resource "azurerm_automation_account" "example" {
  name                = "account1"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  sku_name            = "Basic"
}

resource "azurerm_automation_module" "computer_management_dsc" {
  name                    = "ComputerManagementDsc"
  resource_group_name     = azurerm_resource_group.example.name
  automation_account_name = azurerm_automation_account.example.name

  module_link {
    uri = "https://devopsgallerystorage.blob.core.windows.net/packages/computermanagementdsc.8.5.0.nupkg"
  }
}

Debug Output/Panic Output

azurerm_automation_module.computer_management_dsc: Creating...
Error: A resource with the ID "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/example-resources/providers/Microsoft.Automation/automationAccounts/account1/modules/ComputerManagementDsc" already exists - to be managed via Terraform this resource needs to be imported into the State. Please see the resource documentation for "azurerm_automation_module" for more information.
│ 
│   with azurerm_automation_module.automation_modules["ComputerManagementDsc"], on automation_account-modules.tf line 25, in resource "azurerm_automation_module" "computer_management_dsc":
│   25: resource "azurerm_automation_module" "computer_management_dsc" {
│ 
╵

Expected Behaviour

The module should be able to be imported with the newer version (the default supplied with Automation Accounts is (currently) 5.0.0.0).

Actual Behaviour

The module can't be imported, and there's no way to force it to import with a newer version. I suppose you could try to import the existing module and then set it to use a newer version, but that's not a very elegant solution.

Steps to Reproduce

1. terraform apply

Important Factoids

No response

References

https://docs.microsoft.com/en-us/azure/automation/shared-resources/modules#default-modules

[wuxu92]

Hi, @prubis thanks for your feedback. the azurerm version you used seems a little bit old, could you please have a try with the newest version (3.20.0) to see if this issue still exists?

[prubis]

It is a bit old, I agree! I'm stuck with 2.95.0 until #16103 is resolved.

But I did test with 3.20.0, and experienced the same issue.

[wuxu92]

@prubis you can create it with a new name but not ComputerManagementDsc, because ComputerManagementDsc is a built-in module existing under the automation account.

or you can import this model first, and then do a terraform apply to update the module link like:

terraform import azurerm_automation_module.computer_management_dsc /subscriptions/{xxxx-xxxx-xxxx-xxxxx-xxxxxxx}/resourceGroups/{example-resources}providers/Microsoft.Automation/automationAccounts/account1/modules/ComputerManagementDsc

terraform apply # <- this will do an update on this module

then the module version should fit your expectation.

[prubis]

Hi @wuxu92 you actually can't create it with a new name:

resource "azurerm_automation_module" "computer_management_dsc" {
  name                    = "ComputerManagementDscTest"
  [...]
}

produces:

[...]
azurerm_automation_module.computer_management_dsc: Still creating... [8m21s elapsed]
╷
│ Error: waiting for Module: (Name "ComputerManagementDscTest" / Automation Account Name "account1" / Resource Group "example-resources") to finish provisioning: Orchestrator.Shared.AsyncModuleImport.ModuleImportException: Cannot import the module of name ComputerManagementDscTest, as the module structure was invalid.
│    at Orchestrator.Activities.GetModuleMetadataAfterValidationActivity.ExecuteInternal(CodeActivityContext context, Byte[] moduleContent, String moduleName, ModuleLanguage moduleLanguage)
│    at Orchestrator.Activities.GetModuleMetadataAfterValidationActivity.Execute(CodeActivityContext context)
│    at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager)
│    at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)
│
│   with azurerm_automation_module.computer_management_dsc,
│   on main.tf line 8, in resource "azurerm_automation_module" "computer_management_dsc":
│    8: resource "azurerm_automation_module" "computer_management_dsc" {
│
╵

I agree that yes, you can manually import the newer module version into the Automation Account, and then manually import that into your own TF state file...but at that point, surely you would agree we entering into bug territory.

I feel like this bug can be resolved by checking the isGlobal property of the existing module; if isGlobal is true, then azurerm_automation_module should proceed with the import.

[wuxu92]

@prubis en yes, I think you are right. I'll create a PR to work around this.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.