[bug] Unable to deploy virtual_hub_connections in another subscription

[BartVanBerkel]

Describe the bug We are unable to deploy the virtual_hub_connections. In our case the vnet which we want to connect is in a different subscription than the virtualhub.

The idea is that 'local.connectivity_subscription_id' and 'local.connectivity_tenant_id' should be set to the subscription where the virtual hub is deployed. This can be achieved by setting the 'custom_variables.virtual_hub_lz_key'.

What I have found is that the 'local.tfstates' doesn't contain the right information. The result is that the 'local.connectivity_subscription_id' will be set to the current subscription.

To Reproduce Steps to reproduce the behavior:

1. Deploy virtualhub in subscription A
2. Deploy a vnet in subscription B and add the virtual_hub_connections

Configuration (please complete the following information):

• Version of the rover: aztfmod/rover:1.1.7-2203.2311
• Version of the landing zone: 2203.1

Additional context What I did to fix this issue is update caf_solution/main.tf

  tfstates = merge(
    tomap(
      {
        (var.landingzone.key) = local.backend[var.landingzone.backend_type]
      }
    )
    ,
    try(data.terraform_remote_state.remote[var.landingzone.global_settings_key].outputs.tfstates, {}),
    try(data.terraform_remote_state.remote[local.custom_variables.virtual_hub_lz_key].outputs.tfstates, {})   <= add this line
  )

[nusrath432]

Hi, I have same use case and I tested by adding the above line:

try(data.terraform_remote_state.remote[local.custom_variables.virtual_hub_lz_key].outputs.tfstates, {})

and it worked fine - adding and removing the connection - no issues. No changes to tfvars.

@BartVanBerkel Thanks

But as an interim solution, we are creating a separate landingzone/tfstate to maintain only virtual_hub_connections, using -target_subscription "hub-subscription-id".

[shaneholder]

I also just hit this issue trying to create a vhub connection. using 2203.1. And also confirm that the change in main.tf adding

try(data.terraform_remote_state.remote[local.custom_variables.virtual_hub_lz_key].outputs.tfstates, {}) 

to line 62 allowed the connection to the vhub to be created. Guess I'll be creating a fork.

Many thanks @BartVanBerkel

[shaneholder]

It's been a while since this issue was reported and it seems that it is a blocker to building out a subscription vending machine scenario (which I am doing). I checked a few branches and I do not see the suggested change having been incorporated and I am wondering if there is an alternative solution or if there is a concern about the suggested fix impacting other areas.