[AVM Module Issue]: associatedKeyVaultResourceId parameter for ML workspace causing deployment error when null

[DavidSP-Transparity]

Check for previous/existing GitHub issues

• I have checked for previous/existing GitHub issues

Issue Type?

Bug

Module Name

avm/res/machine-learning-services/workspace

(Optional) Module Version

No response

Description

I have noticed that there's an issue with the resource provider used in this module, which is affecting the module's consumption (including linked modules).

This seems to be the case for the resource provider, even the latest version 'Microsoft.MachineLearningServices/workspaces@2024-07-01-preview'.

The deployment error is generic, and is as follows:

{
"code": "InternalServerError",
"message": "InternalServerError"
}

From my extensive testing, this seems to have been caused by the newly added preview feature which accepts null to use a Microsoft-managed Key Vault as your credential store - Microsoft-managed credential store (preview).

To replicate the issue:

• Create a Resource Group and deploy the following code, with deployKeyVault set to false. It should deploy successfully.
• Make no changes and redeploy the code. It should result in InternalServerError for the project ML workspace resource
• Create a new Resource Group, but this time with deployKeyVault set to true, and it should deploy successfully.
• Make no changes and redeploy the code. It should redeploy successfully.

var sku = 'Standard'
var location = 'uksouth'
var prefix = uniqueString(resourceGroup().id)
var deployKeyVault = false

resource workspaceProject 'Microsoft.MachineLearningServices/workspaces@2024-07-01-preview' = {
  name: 'proj-${prefix}'
  location: location
  properties: {
    friendlyName: 'proj-${prefix}'
    systemDatastoresAuthMode: 'identity'
    hubResourceId: workspaceHub.id
  }
  identity: {
    type: 'SystemAssigned'
  }
  kind: 'Project'
  sku: {
    name: sku
    tier: sku
  }
}

resource workspaceHub 'Microsoft.MachineLearningServices/workspaces@2024-07-01-preview' = {
  name: 'hub-${prefix}'
  location: location
  properties: {
    friendlyName: 'hub-${prefix}'
    storageAccount: storageAccount.outputs.resourceId
    keyVault: deployKeyVault ? keyVault.outputs.resourceId : null // if Key Vault isn't associated, it generates 'InternalServerError' when redeploying the template.
    managedNetwork: {
      isolationMode: 'Disabled'
    }
    publicNetworkAccess: 'Enabled'
    ipAllowlist: []
    workspaceHubConfig: {
      defaultWorkspaceResourceGroup: resourceGroup().id
    }
    enableDataIsolation: true
    systemDatastoresAuthMode: 'identity'
  }
  identity: {
    type: 'SystemAssigned'
  }
  kind: 'Hub'
  sku: {
    name: sku
    tier: sku
  }
}

module keyVault 'br/public:avm/res/key-vault/vault:0.10.2' = if (deployKeyVault) {
  name: take('keyVault-${prefix}-Deployment', 64)
  params: {
    name: 'kv-${prefix}'
    sku: 'standard'
    location: location
    enablePurgeProtection: true
    enableSoftDelete: true
    enableRbacAuthorization: true
    softDeleteRetentionInDays: 7
    networkAcls: {
      defaultAction: 'Allow'
      bypass: 'AzureServices'
    }
    publicNetworkAccess: 'Enabled'
  }
}

module storageAccount 'br/public:avm/res/storage/storage-account:0.14.3' = {
  name: take('storageAccount-st${toLower(replace(prefix, '-', ''))}-Deployment', 64)
  params: {
    name: 'st${prefix}'
    location: location
    skuName: 'Standard_LRS'
    accessTier: 'Cool'
    allowBlobPublicAccess: false
    minimumTlsVersion: 'TLS1_2'
    allowSharedKeyAccess: false
    defaultToOAuthAuthentication: true
    blobServices: {
      automaticSnapshotPolicyEnabled: true
      containerDeleteRetentionPolicyDays: 10
      containerDeleteRetentionPolicyEnabled: true
      deleteRetentionPolicyDays: 9
      deleteRetentionPolicyEnabled: true
      lastAccessTimeTrackingPolicyEnabled: true
    }
    enableHierarchicalNamespace: false
    managedIdentities: {
      systemAssigned: true
    }
    publicNetworkAccess: 'Enabled'
    networkAcls: {
      defaultAction: 'Allow'
      bypass: 'AzureServices'
    }
    requireInfrastructureEncryption: true
    sasExpirationPeriod: '180.00:00:00'
  }
}

(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]

@DavidSP-Transparity, thanks for submitting this issue for the avm/res/machine-learning-services/workspace module!

Important

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

[cecheta]

Hi @DavidSP-Transparity, thanks for raising this issue.

To me, it seems like this is an issue with the ARM resource provider rather than the avm/res/machine-learning-services/workspace AVM module? If that is the case, it may be better to raise a support request within Azure.

[DavidSP-Transparity]

Hi @DavidSP-Transparity, thanks for raising this issue.

To me, it seems like this is an issue with the ARM resource provider rather than the avm/res/machine-learning-services/workspace AVM module? If that is the case, it may be better to raise a support request within Azure.

@cecheta - Yes that's right, it is. Apologies as I thought it would be best to log here. I'll raise a support request with Azure.

I do think it's a good idea to keep this issue open until I get confirmation from Microsoft that it's been resolved, would you agree? I also think it would be good to add a note to the AVM module for anyone using it in the way I described. Something like this? :-

"If you provide a null or empty value for the parameter 'associatedKeyVaultResourceId' to utilise a Microsoft-managed Key Vault as your credential store (Microsoft-managed credential store (preview)), then you may experience a deployment error as 'InternalServerError'.

You can track the issue at: GitHub #3849."

[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)!

[cecheta]

I will see if I can find time to update the description, however in the meantime a contribution would be welcome!