Is this a bug in ARM template for `userAssignedIdentities`?-CodePudding

I've created a Bicep template. In it I create a user-assigned identity and reference it in other resources like this

resource userId 'Microsoft.ManagedIdentity/userAssignedIdentities@2018-11-30' = {
  name: identityName
  location: resourceGroup().location  
}

resource someThing '...' = {
  ...
  dependsOn: [
    userId 
  ]
  ...
}

Whenever I deploy this I need 2 runs. The first run ends in the error message:

Principal XXX does not exist in the directory YYY

where XXX would be a principal id the user-assigned identity has and YYY is my tenant id. If I now look into the portal the identity is created and XXX is the correct id.

So when I now simply re-run the deployment it works.

I consider it a bug in dependsOn which should relate to ARM templates and not Bicep. I could not find any place where I can report ARM template issues to Microsoft.

I'm asking to assure that I do not miss something else here.

CodePudding user response：

So bicep does not require the dependsOn segment if referencing the property correctly.

Need to reference the properties.principalId of the userId in the resource block.

So would look like:

userId.properties.principalId

Here's a quickstart that calls out in a working example how this would work.

CodePudding user response：

You need to reference a newly created identity inside identity property of the target resource. dependsOn is redundant because bicep creates resources in the correct order based on actual usage:

resource userId 'Microsoft.ManagedIdentity/userAssignedIdentities@2018-11-30' = {
  name: 'myidentity'
  location: resourceGroup().location
}

resource appService 'Microsoft.Web/sites@2021-02-01' = {
  name: 'appserviceName'
  location: resourceGroup().location
  properties: {
    //...
  }
  identity: {
    type: 'UserAssigned'
    userAssignedIdentities: {
      '/subscriptions/{your_subscription_id}/resourceGroups/${resourceGroup().name}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/${userId.name}': {}
    }
  }  
}

The documentation doesn't recommend to use dependsOn without as strong reason:

In most cases, you can use a symbolic name to imply the dependency between resources. If you find yourself setting explicit dependencies, you should consider if there's a way to remove it.