Solving BCP178 with "inline" modules

[mitchdenny]

Is your feature request related to a problem? Please describe. One of the problems that I was hoping that Bicep would solve more cleanly for me is the need to create a parent dnsZone and a child dnsZone and create the NS delegation records in the parent zone. Here is my Bicep file where I attempt to do this:

param baseDomainName string = 'parent'
param location string = resourceGroup().location

resource parentDomain 'Microsoft.Network/dnsZones@2018-05-01' = {
  name: '${baseDomainName}-domain.io'
  location: location
}

resource childDomain 'Microsoft.Network/dnsZones@2018-05-01' = {
  name: 'child.${baseDomainName}-domain.io'
  location: location
}

resource childDomainDelegation 'Microsoft.Network/dnsZones/NS@2018-05-01' = {
  name: '${baseDomainName}-domain.io/child'
  properties: {
    NSRecords: [for dnsServer in childDomain.properties.nameServers: {
      nsdname: dnsServer
    }]
  }
}

Unfortunately, just like ARM I can't do this in a single file. In the case of Bicep I get a warning for the childDomain.properties.nameServers usage.

Describe the solution you'd like If I could wave a magic wand, ARM would be able to handle this. But assuming this platform limitation is hard to remove I'd like Bicep to do the heavy lifting for me. When I look at the way the DNS Zone extension for the Azure Portal solves this, it calls out to a separate deployment template which takes care of the delegation.

If my magic wand isn't as powerful I would love Bicep to support the concept of a inline modules which if used results in two JSON templates being generated from the build taking care of the references for me. It might look something like this:

param baseDomainName string = 'parent'
param location string = resourceGroup().location

resource parentDomain 'Microsoft.Network/dnsZones@2018-05-01' = {
  name: '${baseDomainName}-domain.io'
  location: location
}

resource childDomain 'Microsoft.Network/dnsZones@2018-05-01' = {
  name: 'child.${baseDomainName}-domain.io'
  location: location
}

module delegateDomains = {
  resource childDomainDelegation 'Microsoft.Network/dnsZones/NS@2018-05-01' = {
    name: '${baseDomainName}-domain.io/child'
    properties: {
      NSRecords: [for dnsServer in childDomain.properties.nameServers: {
        nsdname: dnsServer
      }]
    }
  }
}

I'm not too attached to the syntax, but the idea is that an inline module is just a module where there is no reference to another .bicep file and the parameters and outputs are inferred from what is consumed-from/used-by the enclosing scope.

[alex-frankel]

I would love Bicep to support the concept of a inline modules

If we allowed this, I think you'd have to pass in relevant parameters just like in a multi-file module declaration in order to preserve the say parameter scoping works in bicep. Something like:

module delegateDomains = {
   params: {
     nameServers: childDomain.properties.nameServers
   }
   code: {
     param nameServers array    

     resource childDomainDelegation 'Microsoft.Network/dnsZones/NS@2018-05-01' = {
      name: '${baseDomainName}-domain.io/child'
      properties: {
        NSRecords: [for dnsServer in nameServers: {
          nsdname: dnsServer
        }]
      }
  }
}

With the extra code required, does that still work for you?

[mitchdenny]

I'd probably take anything that allows me to do this in a single Bicep template ;) That said is there a reason why the compiler couldn't figure it out itself? Other than being more verbose, what would this more explicit syntax get me as a user?

[anthony-c-martin]

@alex-frankel - the restriction on deploy-time constants for property loops feels like something we should be able to address in the intermediate language. Wouldn't that be another option for solving this particular issue?

[alex-frankel]

Good point - that would be a better solution

[alex-frankel]

Raised #4666

[slavizh]

+1

[slavizh]

You should be able to do this:

param wafPolicyId string
param associations array

resource symbolicName 'Microsoft.Cdn/profiles/securityPolicies@2020-09-01' = {
  name: 'someName'
  properties: {
    parameters: {
      type: 'WebApplicationFirewall'
      associations: [for (association, i) in associations: {
        domains: [for (domain, i) in association.domains: {
          id: domain.id
        }]
        patternsToMatch: association.patterns
      }]
      wafPolicy: {
        id: wafPolicyId 
      }
    }
  }
}

This will help with not having to create modules that collect and transform. Creating such results in longer deployment times.

//cc @alex-frankel @anthony-c-martin

[mitchdenny]

What would this look like applied to the DNS scenario that I sketched out above?

Nevermind, its covered in the new issue.