Name: and Parent: values with modules.

[jhoneill]

Background: I need to create 4 virtual networks, 3 of them have an identical first subnet; so to keep the bicep compact, I created a file module_vNet.bicep which creates the Vnet and optionally a subnet and I call it 4 times similar to the following.

param vNet_Foo_First16Bits string = '192.163'
var   vNet_Foo_Name               = 'Foo'

module vnet_Foo  'module_vNet.bicep' = {
  name: vNet_Foo_Name
  params: {
    addressStart: vNet_Foo_First16Bits
    name: vNet_Foo_Name
    withSubnet: false
  }
}

I don't know what a module name should be I re-use the name of the main resource in the module.
After adding a second subnet "bar" I needed to add network peering - there's nothing special about the Vnets and peering, any related resources would do the same thing.

Unlike a resource a module doesn't become a single object for use later in the script: to connect resources to one defined the module, my file module_vNet.bicep ends with

output id string = vnet.id

so I can refer to the vnet's ID later with vnet_Foo.outputs.id and I use this in the peering.

resource vnetPeering_FooToBar 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2020-11-01' = {
  parent: vnet_Foo
  name: 'vnet_${vnet_Foo.name}/PeeringToBar'
  properties: {
    remoteVirtualNetwork: {
      id: vnet_Bar.outputs.id
    }
    remoteAddressSpace: {
      addressPrefixes: [
        '${vnet_BarFirst16Bits}.0.0/16'
      ]
    }
  }
}

(I have removed some of the properties to save space.)
There is a problem here - parent is not a resource, it is module which creates multiple resources. There is (obviously) a need to say resources depend on modules, but there doesn't seem to be a way of saying this resource is the child of some specific resource defined in the module. if vnet_foo were a resource the name of the child could be simply PeeringToBar but in this case it needs to be vnet_foo/PeeringToBar

This works, but uses multiple longish blocks for peering which I would like to replace with calls to a module, if I put the code above into a module file Name, ID and addressPrefixes become parameters and I'd expect to call it like this:

module peer_foo_and_bar 'module_NetPeering.bicep' = {
  name: '${vnet_Foo.name}/Peering'
  params: {
    addressPrefixes: [
      '${vNet_Foo_First16Bits}.0.0/16'
    ]
    id:  vnet_Foo.outputs.id
    name: '${vnet_Foo.name}/Peering'
  }
}

VScode and bicep build have no problem with this but when I go to deploy it, this error results.

InvalidTemplate - Long running operation failed with status 'Failed'. 
Additional Info:'Deployment template validation failed: 'The template resource 'foobar/Peering' for type 'Microsoft.Resources/deployments' at line '1' and column '2311' has incorrect segment lengths. 
A nested resource type must have identical number of segments as its resource name. 
A root resource type must have segment length one greater than its resource name. 
Please see https://aka.ms/arm-template/#resources for usage details.'.'

It's not the most helpful error, especially because the bicep has been transformed so I can't see where the error is or what segment lengths are wrong. By a process of trial and error I can find my use of the resource name as the module name is the problem. In the JSON it looks like this

 {
      "type": "Microsoft.Resources/deployments",
      "apiVersion": "2019-10-01",
      "name": "[format('{0}/Peering', variables('vNet_Foo_Name'))]",
   ...

and the problem is solved by changing the name line to

      "name": "wibble",

Which throws out some questions
Is allowing Parent to be a module a good idea ?
Why are the internal names of modules required ? Someone might want to specify them but any unique name works, so it could be populated automatically.
Why doesn't VS code pick up the wrong number of segments here as it does in some other cases ?

Thoughts ?

[brwilkinson]

In case this helps here is a sample VNET and also VNET Peering template.

https://github.com/brwilkinson/AzureDeploymentFramework/blob/main/ADF/bicep/VNET.bicep
https://github.com/brwilkinson/AzureDeploymentFramework/blob/main/ADF/bicep/VNET-Peering.bicep

If I look in the second file for the Peering I see.

resource VNETPeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2017-10-01' = {
  name: peeringName
  parent: VNETHUB

Notice since I am using the parent, which references the VNET, I only need to provide the single segment for the peering name.

If I look at your sample:

resource vnetPeering_FooToBar 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2020-11-01' = {
  parent: vnet_Foo
  name: 'vnet_${vnet_Foo.name}/PeeringToBar'

it looks as if that should be:

resource vnetPeering_FooToBar 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2020-11-01' = {
  parent: vnet_Foo
  name: 'PeeringToBar'

[jhoneill]

@brwilkinson Thanks.
That second last example is the problem in a nutshell

resource vnetPeering_FooToBar 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2020-11-01' = {
  parent: vnet_Foo
  name: 'PeeringToBar'

Is correct IF vnet_Foo is a vnet resource.
But if vnet_foo is a module (as in this case) bicep can't (doesn't) do that , so I needed to write "parantname/childname" as if there was no parent just a dependsOn.

[brwilkinson]

Yes, that would be correct. Did you have a specific question or suggestion around the behavior/functionality etc?

It appears that you have a working solution?

[brwilkinson]

just so you don't have to repeat yourself,...

I guess you are saying... you would like a build/compile time warning/error to be thrown if when calling a module, there is an extra '/' in the path. Or at least a linting warning/error ? Because at the moment it's a runtime error? Does that sound right?

module peer_foo_and_bar 'module_NetPeering.bicep' = {
  name: '${vnet_Foo.name}/Peering'

[jhoneill]

@brwilkinson - sorry for the slow answer. There are multiple things at play here,

This stems from our first use of bicep to do something which will be used by real customers so we discovered a lot of new things.
We had to create scripts to copy a developer environment which had "grown organically" (i.e. lacked specification); exporting its resource group as one arm template gave over 350 resources and nearly 8000 lines of JSON. One goal was to remove a lot of the repetition, e.g. we had multiple SQL databases and as exported they are ~ 200 lines of Bicep. But we can make that a module and just call it with the server, dbname, and sizing required. When I wrote it I didn't have a lot of confidence in passing resources into modules., so one bicep file creates the server and another calls the module to add the databases and the module looks like this.

resource sqlServer 'Microsoft.Sql/servers@2021-02-01-preview' existing = {
  name: sqlServerName
}
resource db 'Microsoft.Sql/servers/databases@2021-02-01-preview' = {
  name: '${sqlServerName}/${dbName}'
  ...
    dependsOn: [
    sqlServer
  ]

(for me), this works when none of the non-repeating parts (in the calling script) depends on a repeating part (in the module)

But for vnets things are more complicated. Their subnets looked so different that I made each one is a resource which depending on one of the resources in the module. If I write that dependency using parent vscode says "No, I can't make a full name from that parent" , like this

I think it should say "That's a not a valid parent" - it does do a check for the right type of resource:

But instead of saying "Nothing is a valid child of a module" (use dependson instead of parent) it says "anything is a valid child of a module" . Although the message in the first screen grab could be clearer, it does tell me bicep can't derive the full resource name if the parent is a module and it a two part name.

Once I had the subnets using a module to make creating the resources for peering seemed like a good optimization. Because nothing I've read on modules tells me what the function of the name field is I just make it the name of of main object inside the module - which will be wrong in this case. And the error isn't "Your module becomes a nested deployment and those must have single part names", so (a) the VS Code extension should warn me and (b) if I persist it should be a compile time error. But why does a module need a human entered name at all? Why doesn't the compiler just assign one and leave me out of the process ?

[brwilkinson]

Yes, I can see what you mean there, specifically calling a Module instead of the actual vnet resource itself.

One thing I can add, is that some changes were already made about some of this messaging in the latest release #3025 which does a check for the slashes, which was related to this issue #2895 <-- interestingly that is kind of the exact opposite of what you mention 🙂

So I think the way forward maybe to "create issue from discussion". To improve the messaging and add the check around names of things that depend on Modules via name/scope/dependson checks.

--

Just a few things to add separate to your conversation:

• When you deploy the vnet independently and not define all of the subnets, you actually clear/remove the subnets
  • If there are resources on the subnet, you will get an error deploying since it cannot delete the subnets.
• Then later when the subnet code runs it will add them back in if they were deleted or update them accordingly.
• To avoid that scenario you should put the subnets as a loop property of the vnet. That looks something like this
  https://github.com/brwilkinson/AzureDeploymentFramework/blob/2083f3021d86d9865453a1772e9dd7edc28734ec/ADF/bicep/VNET.bicep#L106
• in your case that would mean moving the subnets into the vnet module as well.

[brwilkinson]

@jhoneill

This is now being addressed in #3889

[brwilkinson]

Also another one with nested deployments for ServiceBus ...

• I searched for SB, note these are all related

Get-AzResourceGroupDeployment -ResourceGroupName ACU1-BRW-AOA-RG-T5 |
where DeploymentName -match SB |
select ProvisioningState, Timestamp, ResourceGroupName, DeploymentName

ProvisioningState Timestamp           ResourceGroupName  DeploymentName
----------------- ---------           -----------------  --------------
Succeeded         8/7/2021 8:42:24 PM ACU1-BRW-AOA-RG-T5 dpACU1-BRW-AOA-T5-privatelinkloopSBBUSOrderTracking
Succeeded         8/7/2021 8:42:29 PM ACU1-BRW-AOA-RG-T5 dpACU1-BRW-AOA-T5-privatelinkloopSBESHOPSB
Succeeded         8/7/2021 8:41:34 PM ACU1-BRW-AOA-RG-T5 dpACU1-BRW-AOA-T5-SBDeployESHOPSB
Succeeded         8/7/2021 8:41:31 PM ACU1-BRW-AOA-RG-T5 dpACU1-BRW-AOA-T5-SBDeployBUSOrderTracking
Succeeded         8/7/2021 8:42:39 PM ACU1-BRW-AOA-RG-T5 ACU1-T5-AOA-SB

[jhoneill]

@brwilkinson
Ah. That's something I didn't get before, thanks.
But I still think if the script doesn't set a name for a module, bicep could autogenerate one. :-)

[brwilkinson]

so @jhoneill since this is now being tracked via #3889 are you fine to mark it as answered ?

[jhoneill]

@brwilkinson I've marked it as answered. Now I understand it better I think I have two separate changes to suggest.

[brwilkinson]

Sounds good, thanks James.

If you want to test it out try:

Bicep build mytemplate.bicep

That way you can review what gets compiled and view the names that are generated on the resources and for modules, the deployment names.