azurenoops / ref-scca-enclave-landing-zone-starter

A reference implementation of an SCCA-compliant Mission Enclave landing zone that supports running Azure PaaS services using Azure NoOps.
2 stars 7 forks source link

LZ Starter fails on Spoke VNet peering when more than one subnet is defined #76

Closed sstjean closed 2 months ago

sstjean commented 6 months ago

The Landing Zone Starter will fail when a spoke is defined with more than one subnet with an error that the peering can't be completed because the VNet is still updating subnets.

This issue is for a: (mark with an x)

- [x] bug report -> please search issues before submitting
- [ ] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

  1. Define a spoke VNet (DevSecOps works) with two or more subnets as shown below.
devsecops_subnets = {
  default = {
    name                                       = "devsecops"
    address_prefixes                           = ["10.8.7.224/27"]
    service_endpoints                          = [
      "Microsoft.KeyVault",      
      "Microsoft.Storage", 
    ]
    private_endpoint_network_policies_enabled  = false
    private_endpoint_service_endpoints_enabled = true
  },
  private-endpoints = {
    name                                       = "pe"
    address_prefixes                           = ["10.8.7.96/27"]
    service_endpoints                          = ["Microsoft.Storage", "Microsoft.KeyVault"]
    private_endpoint_network_policies_enabled  = false
    private_endpoint_service_endpoints_enabled = true
  },
  vm = {
    name                                       = "vm"
    address_prefixes                           = ["10.8.7.64/27"]
    service_endpoints                          = ["Microsoft.Storage", "Microsoft.KeyVault"]
    private_endpoint_network_policies_enabled  = false
    private_endpoint_service_endpoints_enabled = true
  }
}
  1. Run a terraform apply

Any log messages given by the failure

Expected/desired behavior

Peering completes successfully to the Hub VNet

OS and Version?

n/a

Versions

v1.6.6

Mention any other details that might be useful


Thanks! We'll be in touch soon.

sstjean commented 6 months ago

lOOKS LIKE WE NEED TO GO INTO THE mANAGEMENT_SPOKE CODE AND ADD A TIMER DELAY ON THE PEERING WAITING FOR SUBNETS TO BE CREATED. Looks like we need to go into the Management Spoke code and add a Timer delay on the peering so that it waits for the subnets to be created. There is example code in the DMZ Spoke Overlay.

resource "time_sleep" "wait_for_subnets"{
  depends_on = [azurerm_subnet.default_snet, data.azurerm_virtual_network.hub_vnet]
  create_duration = "60s"
}

from DMZ Spoke Peerings file