Cluster-api-provider-azure: Cluster-Template Ordering

[zawachte-msft]

/kind bug

What steps did you take and what happened:
[A clear and concise description of what the bug is.]

Looking at the cluster-template.yaml for other CAPI infra providers, they all make sure to order the template objects before the objects that reference them. The base cluster-templete.yaml for azure has the reverse order.

This can lead to a timing issue when core CAPI is reconciling the machinedeployment and fails to find the external template, which will lead to a delay in the worker node coming up.

i.e this ...
````
apiVersion: cluster.x-k8s.io/v1alpha3
kind: MachineDeployment
metadata:
name: ${CLUSTER_NAME}-md-0
spec:
clusterName: ${CLUSTER_NAME}
replicas: ${WORKER_MACHINE_COUNT}
selector:
matchLabels: null
template:
spec:
bootstrap:
configRef:
apiVersion: bootstrap.cluster.x-k8s.io/v1alpha3
kind: KubeadmConfigTemplate
name: ${CLUSTER_NAME}-md-0
clusterName: ${CLUSTER_NAME}
infrastructureRef:
apiVersion: infrastructure.cluster.x-k8s.io/v1alpha3
kind: AzureMachineTemplate
name: ${CLUSTER_NAME}-md-0

version: ${KUBERNETES_VERSION}

apiVersion: infrastructure.cluster.x-k8s.io/v1alpha3
kind: AzureMachineTemplate
metadata:
name: ${CLUSTER_NAME}-control-plane
namespace: default
spec:
template:
spec:
location: ${AZURE_LOCATION}
osDisk:
diskSizeGB: 128
managedDisk:
storageAccountType: Premium_LRS
osType: Linux
sshPublicKey: ${AZURE_SSH_PUBLIC_KEY}
vmSize: ${AZURE_CONTROL_PLANE_MACHINE_TYPE}

should be this right?

---

apiVersion: infrastructure.cluster.x-k8s.io/v1alpha3
kind: AzureMachineTemplate
metadata:
name: ${CLUSTER_NAME}-control-plane
namespace: default
spec:
template:
spec:
location: ${AZURE_LOCATION}
osDisk:
diskSizeGB: 128
managedDisk:
storageAccountType: Premium_LRS
osType: Linux
sshPublicKey: ${AZURE_SSH_PUBLIC_KEY}

vmSize: ${AZURE_CONTROL_PLANE_MACHINE_TYPE}

apiVersion: cluster.x-k8s.io/v1alpha3
kind: MachineDeployment
metadata:
name: ${CLUSTER_NAME}-md-0
spec:
clusterName: ${CLUSTER_NAME}
replicas: ${WORKER_MACHINE_COUNT}
selector:
matchLabels: null
template:
spec:
bootstrap:
configRef:
apiVersion: bootstrap.cluster.x-k8s.io/v1alpha3
kind: KubeadmConfigTemplate
name: ${CLUSTER_NAME}-md-0
clusterName: ${CLUSTER_NAME}
infrastructureRef:
apiVersion: infrastructure.cluster.x-k8s.io/v1alpha3
kind: AzureMachineTemplate
name: ${CLUSTER_NAME}-md-0
version: ${KUBERNETES_VERSION}

[CecileRobertMichon]

Great question @zawachte-msft. The capz templates are auto-generated by kustomize with make generate-flavors. For example, the default cluster-template.yaml uses this kustomization https://github.com/kubernetes-sigs/cluster-api-provider-azure/blob/master/templates/flavors/default/kustomization.yaml which does put machine-deployment after the base template. I think we can leverage the --reorder none kustomize flag to keep the order the resources are listed in https://github.com/kubernetes-sigs/kustomize/blob/master/docs/v2.1.0.md#resource-ordering.

/cc @devigned

[devigned]

Seams reasonable to use the --reorder none flag.

I noticed the ordering, but had hoped the impact would be less than would be noticed. Apparently, it is noticeable. It should be corrected.

[CecileRobertMichon]

SGTM. I can open a PR.

/assign