Cluster-api-provider-azure: using AZURE_JSON_B64 doesn't allow for custom subnet names

[nader-ziada]

/kind bug

What steps did you take and what happened:
[A clear and concise description of what the bug is.]
using AZURE_JSON_B64 as described in the docs requires the user to generate the same AZURE_JSON_B64 value that would be used for both control plane and node machines, which doesn't allow for the subnet name to be different in the case where the user defined custom subnets with control plane and node roles.

What did you expect to happen:
being able to have different subnet name values for each kind of machine

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• cluster-api-provider-azure version:
• Kubernetes version: (use kubectl version):
• OS (e.g. from /etc/os-release):

[CecileRobertMichon]

The Cloud Provider config subnetName is always the node subnet, even before we started using AZURE_JSON_B64 (check out the templates for https://github.com/kubernetes-sigs/cluster-api-provider-azure/releases/tag/v0.4.5, both control plane and node files have "subnetName": "${CLUSTER_NAME}-node-subnet",. So as long as the user changes the subnet name in the command to generate the base 64 variable it should work the same way as before.

Note that this might become a problem if we want to support multiple node subnets but we'll cross that hurdle when we get there.

[nader-ziada]

but if you are using a custom vnet with custom subnets, don't you need to specify a different subnet name between the azure.json in the control plane machine and the azure.json in the node machine template?

[CecileRobertMichon]

I need to verify this, but I don't think the subnetName needs to be different on the control plane machine vs node machine template. The Azure cloud provider uses Azure.json as config for the for the cloud provider, which only needs to know about the node subnets (where services are exposed).

Maybe @feiskyer @aramase or @jackfrancis can help clarify.

[jackfrancis]

The way this works in AKS Engine is that the azure.json file is common across both control plane and worker node (I'm not 100% confident that the worker nodes actually consume the azure.json in any configuration context in order to retrieve the subnet value: this is effectively a control plane-only configuration, is my understanding).

Additionally, I think it's more correct to say that this value literally represents "the subnet where the control plane nodes can be found", I don't think it has anything to do with providing a reference to which subnet a node can be found.

[nader-ziada]

so it should be controlplane-subnet in both locations of azure.json (control-plane config and node config)?
currently is node-subnet in both

[CecileRobertMichon]

Opened https://github.com/kubernetes-sigs/cluster-api-provider-azure/issues/773

[CecileRobertMichon]

I'm going to close this one for now, we're tracking #773 for auditing the config and the workaround for this issue is to use your own template with a custom azure.json secret value.

/close

[k8s-ci-robot]

@CecileRobertMichon: Closing this issue.

In response to this:

I'm going to close this one for now, we're tracking #773 for auditing the config and the workaround for this issue is to use your own template with a custom azure.json secret value.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.