Update other dev templates to leverage ILB solution

[nawazkh]

Self hosted clusters are leveraging ILB solution to custom resolve workload cluster's API server DNS name with internal IP of the ILB.
We do this by updating the /etc/hosts of the worker nodes of the workload cluster.

Since other templates do not necessarily use VM, instead use VMSS etc, we should carry over the internal IP ILB solution to other dev templates as well.

[junkiebev]

In the event that this is done, it's no longer required to create the private DNS zone or the records in it (as far as I can tell), however it doesn't appear possible to "opt out" of the private dns zone being created at present if the AzureCluster.spec.networkSpec.apiServerLB.type is set to Internal

[nawazkh]

In the event that this is done, it's no longer required to create the private DNS zone or the records in it

Do you mean once a template is deployed by an MS tenant (SFI restrictions), a MS dev doesn't need to deploy a private DNS Zone and create a record in the private dns zone once the VNets(management and workload cluster's) are peered ?

however it doesn't appear possible to "opt out" of the private dns zone being created at present if the AzureCluster.spec.networkSpec.apiServerLB.type is set to Internal

I.. don't fully understand this.
"private dns zone" fix is being added only to the tilt workflow for local development.
A new user who is not a MS Tenant, or the tests hosted in test grid, do not need to have a private dns zone work around to work with CAPZ.

Can you please elaborate your thought ?

To add more context: A load balancer of type Internal is created for all flavors of CAPZ unless the flavor is of type "private".