[AVM Module Issue]: Storage Account Blob Containers missing depends on

[GregorLauritz]

Check for previous/existing GitHub issues

• I have checked for previous/existing GitHub issues

Issue Type?

Bug

Module Name

avm/res/storage/storage-account

(Optional) Module Version

0.13.1

Description

In the file blob-service/main.bicep the blobServices_container module has a missing dependsOn for the module blobServices.
This causes deployment failures when using multiple containers with immutableStorageWithVersioningEnabled set to true and isVersioningEnabled set to true for the blob service (probably because the containers are created too early without the depends on).

Fix:

module blobServices_container 'container/main.bicep' = [
  for (container, index) in (containers ?? []): {
    name: '${deployment().name}-Container-${index}'
    dependsOn: [blobServices]
    params: {
      storageAccountName: storageAccount.name
      name: container.name
      defaultEncryptionScope: container.?defaultEncryptionScope
      denyEncryptionScopeOverride: container.?denyEncryptionScopeOverride
      enableNfsV3AllSquash: container.?enableNfsV3AllSquash
      enableNfsV3RootSquash: container.?enableNfsV3RootSquash
      immutableStorageWithVersioningEnabled: container.?immutableStorageWithVersioningEnabled
      metadata: container.?metadata
      publicAccess: container.?publicAccess
      roleAssignments: container.?roleAssignments
      immutabilityPolicyProperties: container.?immutabilityPolicyProperties
    }
  }
]

(Optional) Correlation Id

No response

[microsoft-github-policy-service]

Important

The "Needs: Triage 🔍" 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.

[avm-team-linter]

@Krenol, thanks for submitting this issue for the avm/res/storage/storage-account module!

Important

A member of the @Azure/avm-res-storage-storageaccount-module-owners-bicep or @Azure/avm-res-storage-storageaccount-module-contributors-bicep team will review it soon!

[microsoft-github-policy-service]

Warning

Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

Tip

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage 🔍" label must be removed as part of the triage process (when the issue is first responded to)!

[AlexanderSehr]

Hey @GregorLauritz,
a good find. I would want to suggest a slightly different solution though that actually is a bit more consistent with the general design of AVM.

// blob-service/main.bicep
module blobServices_container 'container/main.bicep' = [
  for (container, index) in (containers ?? []): {
    name: '${deployment().name}-Container-${index}'
    params: {
      storageAccountName: storageAccount.name
+     blobServiceName: blobServices.name
      name: container.name
      defaultEncryptionScope: container.?defaultEncryptionScope
      denyEncryptionScopeOverride: container.?denyEncryptionScopeOverride
      enableNfsV3AllSquash: container.?enableNfsV3AllSquash
      enableNfsV3RootSquash: container.?enableNfsV3RootSquash
      immutableStorageWithVersioningEnabled: container.?immutableStorageWithVersioningEnabled
      metadata: container.?metadata
      publicAccess: container.?publicAccess
      roleAssignments: container.?roleAssignments
      immutabilityPolicyProperties: container.?immutabilityPolicyProperties
    }
  }
]

// blob-service/container/main.bicep
+ @description('Conditional. The name of the parent Blob Service. Required if the template is used in a standalone deployment.')
+ param blobServiceName string = 'default'

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' existing = {
  name: storageAccountName

  resource blobServices 'blobServices@2022-09-01' existing = {
-  name: 'default'
+  name: blobServiceName
  }
}

While this is implicit dependency is definitely more 'complicated' than the explicit dependency you suggested, it would make full use of the interface we have for all modules, that is, passing the name of parents through to their child-modules. The only reason this was handled differently here (presumably) was because the name is always 'default'.

Thoughts?

[GregorLauritz]

I like this solution. Looks good to me.