Incorrect automation region mapping for Log Analytics workspace in East US regions

[autocloudarc]

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

Versions

terraform:

PS [08/29/2022 17:54:49]> terraform -version Terraform v1.1.2 on windows_amd64

azure provider:

• provider registry.terraform.io/hashicorp/azurerm v3.20.0

module: azurerm 2.3.1

Description

When selecting either eastus or eastus2 for the managementresourceslocation variable in variables.tf file, we can't link the log analytics workspace to the automation account.

Describe the bug

This is because these resources cannot be both in the same region at the same time. One has to be in eastus and the other in eastus2. See: https://docs.microsoft.com/en-us/azure/automation/how-to/region-mappings

Steps to Reproduce

1. step 1: Assign the managementresourceslocation variable value to either "eastus" or "eastus2"
2. step 2: Attempt to link the log analytics workspace to the automation account from Update Management to enable the solutions.
3. you get it…See screenshot below.

Screenshots

Additional context

Same issue with ARM template deployment:

Possibility to choose region for Log Analytics / Automation Account resource deployment #244

[krowlandson]

Great catch @autocloudarc... I'll see if we can get this added as a quick bugfix as shouldn't be too hard to address.

Will also talk to the team about how we address this in the ARM and Bicep implementations.

[autocloudarc]

Thanks @krowlandson , for your quick response. :-) It may be worthwile to note that the Bicep implementation works as intended and this isn't an issue because I've had to use it as a workaround for the ARM issue twice before. This is because in Bicep, we can specify the regions for both resources independently (automation account and log analytics workspace), so the issue only occurs for the portal experience and Terraform so far.

[krowlandson]

UPDATED: to correct typo and update syntax

Cool... thank you for confirming. I'll address the Portal experience too when fixing this then 👍🏻

For now (as a tactical work-around), you can actually override the automation account locations using the advanced block. To solve this issue for either location, add the following to your configure_management_settings input variable and the module should utilise the correct location when specifying either eastus or eastus2 as the desired region:

  configure_management_settings= {
    # other settings removed for brevity
    advanced = {
      custom_settings_by_resource_type = {
        azurerm_automation_account = {
          management = {
            location = "eastus"
          }
        }
      }
    }
  }

The relevant code in the module where this is applied can be seen here:

terraform-azurerm-caf-enterprise-scale/modules/management/locals.tf

Line 157 in 8cd6f24

location = try(local.custom_settings_aa.location, local.location)

[krowlandson]

@autocloudarc... Please test the above and let me know if this works as expected. I will then apply this logic to the module so you don't need to do this manually.

[krowlandson]

@autocloudarc I can also see this was "addressed" in the Bicep module in Azure/ALZ-Bicep#97 so thank you for confirming.

[autocloudarc]

Thanks again @krowlandson for being so responsive. I copied/pasted these advanced settings into my configure_management_resources input variable (you suggested configure_connectivity_settings input variable), but I believe that may have just been a typo, since these resources are in the management and not the connectivity subscription. The results unfortunately, did not change and both resources were still placed in the eastus2 region.

[krowlandson]

Yes, you're correct... that was a typo! I'll also double check the syntax provided above and come back to you later.

[krowlandson]

@autocloudarc

Actually, not such a difficult one for me to verify... In the connectivity data module we standardised on including the location of the target resource(s) within the map when defining overrides. Within the management data module we didn't.

I've corrected the example above but sadly you will need to correctly specify the pairing as I cannot (at this level) determine how an end user would specify the primary management location to determine this programmatically like I will within the module when implementing a fix.

[autocloudarc]

@krowlandson Thank you! The updated code above works for me now. :-) Made my day!!

[krowlandson]

Awesome, glad this helped @autocloudarc... will keep this issue open until we implement a more permanent fix.

Thank you for confirming that the above worked as a tactical work-around 👍🏻

[jtracey93]

Trigger ADO Sync

[krowlandson]

Trigger ADO Sync