Added several user defined types, ability for custom resources names in vwanConnectivity and mgDiagSettings

[johnlokerse]

Overview/Summary

The changes in this PR allow the user to set custom names for Azure Firewall, Virtual WAN Hubs, ExpressRoute Gateway, and VPN Gateway. Also, for readability, I added the virtualWanOptionsType so the array of objects is easier to understand, read and work with.

Issue: #625

AB#30600

This PR fixes/adds/changes/removes

1. Added virtualWanOptionsType
2. Introduced optional parVpnGatewayCustomName, parExpressRouteGatewayCustomName, parAzFirewallCustomName, and parVirtualWanHubCustomName paramaters to specify custom resource names.
3. Added custom name capability for mgDiagSettings.bicep
4. Added custom name capability for Log Analytics Linked Service
5. Added subnetOptionsType
6. Added nonComplianceMessageType

Breaking Changes

Not breaking due to the conditional values for VWAN module changes as well as new parameters using previously hard coded value

Testing Evidence

Succeeded deployment without custom names (as is situation):

Succeeded deployment with custom names:

As part of this Pull Request I have

• Read the Contribution Guide and ensured this PR is compliant with the guide
• Ensured the resource API versions in .bicep file/s I am adding/editing are using the latest API version possible
• Checked for duplicate Pull Requests
• Associated it with relevant GitHub Issues
• (ALZ Bicep Core Team Only) Associated it with relevant ADO Items
• Ensured my code/branch is up-to-date with the latest changes in the main branch
• Performed testing and provided evidence.
• Updated one or more of the following tests (if required)
  • Unit
  • Linting
  • E2E (End-To-End)
  • ValidateAzCloud (Base validation in Azure Cloud)
  • ValidateMcCloud (Base validation in Azure China Cloud)
• Updated relevant and associated documentation (e.g. Contribution Guide, Module READMEs, Wiki Docs etc.)
• If relevant, created or updated Code Tours here

[jtracey93]

Thanks @johnlokerse,

dont forget to update the parameter input files also 👍

[jtracey93]

@johnlokerse we've got some test failures, could you review and resolve?

Also could you review the other modules to ensure they all allow a custom name for resources, if desired and don't have any hardcoded patterns like this one did?

[johnlokerse]

Added succeeded deployment screenshots

[johnlokerse]

Thanks @johnlokerse,

dont forget to update the parameter input files also 👍

How do we want to present the parameter file? The new properties are fully optional so there is no need to add them to the parameter file. It is only required when you want to use a custom name.

@johnlokerse we've got some test failures, could you review and resolve?

Also could you review the other modules to ensure they all allow a custom name for resources, if desired and don't have any hardcoded patterns like this one did?

Will do! :)

[johnlokerse]

Fixed the broken Action regarding listing the used resource types. The underlying ARM template is different when using User-Defined Types. The Action was looking for the resource type $_.Type but it cannot be found when using User-Defined Types, because the type is nested deeper inside a PSObject.

I have tested this locally and got it working like it was before:

In this test I had two JSON files (hubNetworking.json and policyAssignedManagementGroup.json) with User-Defined Types and one JSON file (publicIp.json) without types.

Can you rerun the Action for me @jtracey93 / @oZakari?

[johnlokerse]

✅ on my end: https://github.com/johnlokerse/ALZ-Bicep/actions/runs/6770957590/job/18400393975

[johnlokerse]

FYI. I am testing something so that I do not have to use the contains method. Much cleaner code and is easier to read. Will commit the change tonight after successful test deployments!

[picccard]

Is there any need for parUseCustomNamingScheme?
Since the custom-names are optional, could you just use the custom-name if any is provided or a default value if omitted?

resource resAzureFirewall 'Microsoft.Network/azureFirewalls@2023-02-01' = [for (hub, i) in parVirtualWanHubs: if ((parVirtualHubEnabled) && (hub.parAzFirewallEnabled)) {
  name: hub.?parAzFirewallName ?? '${parAzFirewallName}-${hub.parHubLocation}'
  // this returns hub.parAzFirewallName if not null, else return default name
  ...
}

[johnlokerse]

Is there any need for parUseCustomNamingScheme? Since the custom-names are optional, could you just use the custom-name if any is provided or a default value if omitted?

resource resAzureFirewall 'Microsoft.Network/azureFirewalls@2023-02-01' = [for (hub, i) in parVirtualWanHubs: if ((parVirtualHubEnabled) && (hub.parAzFirewallEnabled)) {
  name: hub.?parAzFirewallName ?? '${parAzFirewallName}-${hub.parHubLocation}'
  // this returns hub.parAzFirewallName if not null, else return default name
  ...
}

Yes, that was my change to reduce complexity/add readability :-) Thanks for the suggestion @picccard!

Tested the solution through deployments:

Successful deployment without 'custom names':

Successful deployment with 'custom names':

[oZakari]

Thank you much @johnlokerse! I will plan on going through this PR later this week.

Already has been resolved by John

[oZakari]

Hey @johnlokerse, for the VWAN user defined type, I removed the parUseCustomNamingScheme switch references as it looks like you had removed that from the conditions in a previous commit. I also adjusted the properties for the user defined type in that module as well. Does what I changed it to make sense to you?

Everything else looks good for the PR, let me know your thoughts. Thanks again for all of your work with this :)

[johnlokerse]

Looks good to me! Thanks for updating and let me know if I can help with something else 👍🏼💪🏼

[oZakari]

/azp run validateazcloud

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).