5

Microsoft documents the purpose of implicit and explicit dependencies. Where the explicit dependency uses 'dependsOn'. But it is mentioned that use cases for this approach are rare.

Could use some clarification on the following:

Example from MS

resource dnsZone 'Microsoft.Network/dnszones@2018-05-01' = {
  name: 'demoeZone1'
  location: 'global'
}

resource otherZone 'Microsoft.Network/dnszones@2018-05-01' = {
  name: 'demoZone2'
  location: 'global'
  dependsOn: [
    dnsZone
  ]
}

Quote

You can't query which resources were defined in the dependsOn element after deployment.

Assuming 'otherZone' is a dependsOn element, it can still be queried using the symbolic name.

Am I wrong and if so what is meant with the dependsOn element?

Adriaan
  • 17,741
  • 7
  • 42
  • 75
givinUp__
  • 53
  • 1
  • 4

2 Answers2

2

As stated in the article you link to:

The following example shows a DNS zone named otherZone that depends on a DNS zone named dnsZone

This means the otherZone is not the dependsOn element, it has a dependance on the dnsZone.

and

While you may be inclined to use dependsOn to map relationships between your resources, it's important to understand why you're doing it. For example, to document how resources are interconnected, dependsOn isn't the right approach. You can't query which resources were defined in the dependsOn element after deployment. Setting unnecessary dependencies slows deployment time because Resource Manager can't deploy those resources in parallel.

Bicep creates dependencies automatically (implicitly)

Azure Resource Manager evaluates the dependencies between resources, and deploys them in their dependent order. When resources aren't dependent on each other, Resource Manager deploys them in parallel.

So setting them explicitly is not needed in most cases.

rickvdbosch
  • 14,105
  • 2
  • 40
  • 53
  • Thanks for clearing a dependsOn element! The part `can't query after deployment`, does this mean that the dependsOn element isn't traceable in the ARM (in portal) after deployment? – givinUp__ Mar 02 '22 at 12:37
  • dependsOn is only a deploy-time concept, it's a sequencing task - it has no relation to whether or not the resources actually depend on each other after provisioning. Often that's true (i.e. they do) but it need not be. So... you can not look at a resource and see what it's deploy-time dependencies might have been, but you can export the template that created the resource and see any dependsOn that were authored in the template. – bmoore-msft Mar 02 '22 at 23:17
0

The way I see it what they mean is that setting those explicit dependsOn elements without a good (deployment related) reason has no benefit because once the deployment has been done you can't see anywhere (in the Azure Portal) that you had this dependency set in your file.

The use case for dependsOn is if you need to make sure that the Resource Manager will create the resource with the dependOn only after the other resource has been created (and not in parallel).

But in most cases where you would need that you will set a parent relationship anyway which has the same effect (Implicit dependency).

JustAGuy
  • 151
  • 4