panic: runtime error: invalid memory address or nil pointer dereference about kubicorn HOT 2 OPEN

I was having this problem, and it was caused by clusterAPI::spec::providerConfig being empty. The panic is caused by ProviderConfig().SSH being nil here - https://github.com/kubicorn/kubicorn/blob/master/pkg/initapi/ssh.go#L29. If you fix the code to check for nil you still don't get very far because everything else is missing.

I haven't figured out what yet, but something appears to be blanking out that section in cluster.yaml sometimes, possibly after certain errors occur. Solution was to regenerate the file with kubicorn create, or just back it up so you can restore it if something overwrites it.

Edit: This appears to be because the ProviderConfig is cleared once the Reconciler has been created, but if there's another error after that before actual provisioning the ProviderConfig is lost.

Edit2: It's here. At this point newCluster.ClusterAPI.Spec.ProviderConfig is empty. In the case of Azure the cluster object has been (re)constructed in https://github.com/kubicorn/kubicorn/blob/master/cloud/azure/public/resources/resourcegroup.go#L131, which starts with an empty ProviderConfig, and only copies a couple of fields into it from the resourceGroup, and these (in my case) are also empty.

from kubicorn.

I've now played with this a bit more and traced through it many times, and I must be missing something because I can't see how it ever worked. Has anyone successfully deployed an Azure cluster in the last few months?

The thing I can't understand is that, as per my previous comment, resourcegroup.immutableRender() returns a cluster object with the ProviderConfig created from a new struct i.e. empty, so most or all of the original ProviderConfig is lost at this point.

What puzzles me even more is that AtomicReconciler.Actual() is passed in a cluster config in the parameter known, but this is not used in the function, it instead starts with r.known but it loops over the resources and overwrites the actualCluster variable inside the loop, so it only ever returns a cluster object with the resource info of the last resource in the list.

At which point the original ProviderGroup details from cluster.yaml are lost, but they are used after that, like to get the SSH details, and are stored back to the original file, so they are lost forever. You can't even retry.

Sorry if I'm just sharing my ignorance and I'm missing something pretty basic.

from kubicorn.