Azure / bicep-registry-modules

Bicep registry modules
MIT License
434 stars 286 forks source link

[Bug Report]: Issues rerunning compute module when using Recovery Vault that has immutability enabled #2426

Open chris-gibbs opened 7 months ago

chris-gibbs commented 7 months ago

Describe the bug

Unable to re-run compute deploy with same settings / policy without an error.

Originally deployed using the compute module, backups were then enabled after creation of VM by adding in the Vault paramaters for the module. Re-running the deployment post backup deployment without any changes to the 'DefaultPolicy' retention for backups results in error.

To reproduce

  1. Deploy compute from modules/compute/virtual-machine/main.bicep
  2. Enable backup to existing Recovery Vault with immutability enabled and unlocked, deploy using 'DefaultPolicy '
  3. Error. We have multiple VMs where this is an issue. We do have 1 example where it is working though and the experience is not consistent.

Code snippet

param location string

param rgAppName string

param kvName string

param kvRG string

param coreVMName string

param coreVMSubnetID string

param coreVMStaticIPs array

param coreVMBackendStaticIPs array

param coreVMBackendSubnetID array

param coreVMSize string

param coreVMOSDiskSize int

param coreVMOSDiskType string

param coreVMDataDisk1Size int

param coreVMDataDisk1Type string

@description('Optional. Recovery service vault name for backing up VMs, Storage and SQL.')
param recoveryVaultName string = ''

@description('Optional. Resource group of the backup recovery service vault. If not provided the current resource group name is considered by default.')
param backupVaultResourceGroup string = ''

resource kv 'Microsoft.KeyVault/vaults@2022-07-01' existing = {
  name: kvName
  scope: resourceGroup(kvRG)
}

resource rgApp 'Microsoft.Resources/resourceGroups@2021-04-01' = {
  name: rgAppName
  location: location
}

module diskEncryptionSet '../../../../carml/modules/Microsoft.Compute/diskEncryptionSets/deploy.bicep' = : {
  name: 'deploy_${coreVMName}-01-disk-encryption-set'
  scope: appRG
  params: {
    name: '${coreVMName}-01-disk-encryption-set'
    keyName: '${coreVMName}-01-disk-encryption-set'
    keyVaultResourceId: kv.id
    encryptionType: 'EncryptionAtRestWithPlatformAndCustomerKeys'
    location: location
  }
}]

module coreVM '../../../../carml/modules/Microsoft.Compute/virtualMachines/deploy.bicep' = : {
  name: 'deploy_${coreVMName}-01'
  scope: appRG
  params: {
    name: '${coreVMName}-01'
    location: location
    lock: enableResourceLock == true ? resourceLockType : ''
    tags: tags
    adminUsername: coreVMUsername
    imageReference: {
      offer: 'WindowsServer'
      publisher: 'MicrosoftWindowsServer'
      sku: '2019-Datacenter'
      version: 'latest'
    }
    nicConfigurations: [
      {
        nicSuffix: '-nic01'
        ipConfigurations: [
          {
            name: '${coreVMName}-01-nic01-ipconfig01'
            privateIPAddress: coreVMStaticIPs
            privateIPAllocationMethod: 'static'
            privateIPAddressVersion: 'IPv4'
            subnetResourceId: coreVMSubnetID
          }
        ]
      }
      {
        nicSuffix: '-nic02'
        enableAcceleratedNetworking: false
        ipConfigurations: [
          {
            name: '${coreVMName}-01-nic02-ipconfig01'
            privateIPAddress: coreVMBackendStaticIPs
            privateIPAllocationMethod: 'static'
            privateIPAddressVersion: 'IPv4'
            subnetResourceId: coreVMBackendSubnetID
          }
        ]
      }
    ]
    osType: 'Windows'
    vmSize: coreVMSize
    osDisk: {
      createOption: 'FromImage'
      diskSizeGB: coreVMOSDiskSize
      managedDisk: {
        storageAccountType: coreVMOSDiskType
        diskEncryptionSet: {
          id: diskEncryptionSet.outputs.resourceId
        }
      }
    }
    dataDisks: [
      {
        createOption: 'Empty'
        diskSizeGB: coreVMDataDisk1Size
        managedDisk: {
          storageAccountType: coreVMDataDisk1Type
          diskEncryptionSet: {
            id: diskEncryptionSet.outputs.resourceId
          }
        }
      }
    ]
    backupVaultName: !empty(recoveryVaultName) ? recoveryVaultName : ''
    backupVaultResourceGroup: !empty(backupVaultResourceGroup) ? backupVaultResourceGroup : ''
    backupPolicyName: vmBackupPolicyName
  }
}

Relevant log output

Deployment logs show 

"details": [
    {
        "code": "UserErrorModifyPolicyOrProtectionWithReducedRetentionNotSupported",
        "message": "Reduction in retention during Policy/Protection modification is not allowed since the selected vault is immutable."
    }
]
chris-gibbs commented 7 months ago

Workaround is to set the immutability of the Recovery Vault to 'Disabled', rerun pipeline and then set immutability back to 'Unlocked'. However this will only work if immutability has not been set to 'Locked'

AlexanderSehr commented 7 months ago

Hey @chris-gibbs, based on what you described and reviewing the module I can't see any obvious reason why the backup wouldn't be idempontent. @rahalan is currenlty working on porting the resource to AVM and as part of the module's tests actually now tests the idempotency. @rahalan would you have happened to come encounter similar challanges?

microsoft-github-policy-service[bot] commented 1 month ago

[!IMPORTANT] The "Needs: Triage :mag:" label must be removed once the triage process is complete!

[!TIP] For additional guidance on how to triage this issue/PR, see the BRM Issue Triage documentation.

AlexanderSehr commented 1 month ago

Hey @rahalan, I just migrated this issue over from CARML. Please take a look and triage if still relevant :)