Bug: clusterctl fail when using existing external cluster

[sflxn]

Using the clusterctl from this repo fails when using an existing cluster. Using a nested ESX on Fusion on Mac, I attempted to deploy a cluster with the following command,

clusterctl create cluster --existing-bootstrap-cluster-kubeconfig ~/.kube/config -m machines.yaml -c cluster.yaml -p provider-components.yaml --provider vsphere -v 6

What I see is a constant loop waiting for the master to come up,

I0821 08:55:10.288137   70954 clusterdeployer.go:136] Creating cluster object test1 on external cluster
I0821 08:55:10.376143   70954 round_trippers.go:436] POST https://192.168.218.131:8443/apis/cluster.k8s.io/v1alpha1/namespaces/default/clusters 201 Created in 87 milliseconds
I0821 08:55:10.377509   70954 clusterdeployer.go:141] Creating master
I0821 08:55:10.474704   70954 round_trippers.go:436] POST https://192.168.218.131:8443/apis/cluster.k8s.io/v1alpha1/namespaces/default/machines 201 Created in 96 milliseconds
I0821 08:55:10.476449   70954 clusterclient.go:433] Waiting for Machine vs-master-9pmdb to become ready...
I0821 08:55:10.480937   70954 round_trippers.go:436] GET https://192.168.218.131:8443/apis/cluster.k8s.io/v1alpha1/namespaces/default/machines/vs-master-9pmdb 200 OK in 4 milliseconds
I0821 08:55:20.480953   70954 clusterclient.go:433] Waiting for Machine vs-master-9pmdb to become ready...
I0821 08:55:20.576983   70954 round_trippers.go:436] GET https://192.168.218.131:8443/apis/cluster.k8s.io/v1alpha1/namespaces/default/machines/vs-master-9pmdb 200 OK in 95 milliseconds
I0821 08:55:30.484846   70954 clusterclient.go:433] Waiting for Machine vs-master-9pmdb to become ready...
I0821 08:55:30.573614   70954 round_trippers.go:436] GET https://192.168.218.131:8443/apis/cluster.k8s.io/v1alpha1/namespaces/default/machines/vs-master-9pmdb 200 OK in 88 milliseconds
I0821 08:55:40.484931   70954 clusterclient.go:433] Waiting for Machine vs-master-9pmdb to become ready...

What I see from the machine actuator's logs (via kubectl log):

ERROR: logging before flag.Parse: I0821 15:55:34.303364       1 queue.go:38] Start NodeWatcher Queue
ERROR: logging before flag.Parse: I0821 15:55:34.305496       1 queue.go:38] Start Machine Queue
ERROR: logging before flag.Parse: I0821 15:55:34.385695       1 controller.go:91] Running reconcile Machine for vs-master-9pmdb
ERROR: logging before flag.Parse: I0821 15:55:34.475709       1 machineactuator.go:175] Attempting to stage tf state for machine vs-master-9pmdb
ERROR: logging before flag.Parse: I0821 15:55:34.475913       1 machineactuator.go:177] machine does not have annotations, state does not exist
ERROR: logging before flag.Parse: I0821 15:55:34.475995       1 machineactuator.go:658] Instance existance checked in directory
ERROR: logging before flag.Parse: I0821 15:55:34.476064       1 controller.go:134] reconciling machine object vs-master-9pmdb triggers idempotent create.
ERROR: logging before flag.Parse: I0821 15:55:34.672349       1 machineactuator.go:201] Cleaning up the staging dir for machine vs-master-9pmdb
ERROR: logging before flag.Parse: I0821 15:55:34.673281       1 machineactuator.go:175] Attempting to stage tf state for machine vs-master-9pmdb
ERROR: logging before flag.Parse: I0821 15:55:34.673299       1 machineactuator.go:177] machine does not have annotations, state does not exist
ERROR: logging before flag.Parse: I0821 15:55:34.673303       1 machineactuator.go:284] Staged for machine create at /tmp/cluster-api/machines/vs-master-9pmdb/

[sflxn]

I've debugged this further... the hard way, and found the clusterctl simply wasn't bubbling up the actual provisioning error from Terraform. The problem was my machines.yaml provider config.

[sflxn]

This is not a bug. The provider only works with VC, and I was using ESX.