If I could print the kubeconfig, I think I could troubleshoot but I can’t find a way to do that. I always end up with {0x0flj2ij3flk23f] type response which I assume is either a memory address or object that is not fully returned or something.

You can see that here:

KubeConfig: {0x1400004a380}(pall) Args[0]: dimo-dev-401815-e2c3d0d(pall) Args[1]: 35.192.120.34

I’ve added the oauth scopes to the config and that seems to have stopped the cluster recreation (maybe).

Looks like something is putting tabs in my kubeconfig. I’ve confirmed only spaces in the file even after save…

"plaintext": "\"\\napiVersion: v1\\nclusters:\\n- cluster:\\n\\tcertificate-authority-data:

However, it’s complaining about line 5 which is the server line and is after cluster and certificate-authority-data lines.

Is it server name?

I’ve gotten everything else working except for that line 5 error. Using

pulumi stack export --show-secrets

has been really helpful to see the output of the compiled kubeconfig. Just can’t figure out how to get rid of the tabs! Or if thats even the actual problem… Is there anything in Pulumi that adds those tab characters? Or anything in Pulumi that removes them before using the YAML with kubectl?

If I simply copy the kubeconfig from the logs, it works just fine (of course I have no tabs in there and only spaces. Whats odd tho is that if I move lines, i.e. swap line 4 and 5, its still always line 5 that errors which seems fishy to me.

@salmon-account-74572 you happen to have an idea who might be able to point me in the right direction with this one? I’m stumped at this point digging through the library code…

Ok, finally got this resolved. It was due to a \t character that made its way into my go file because of my IDE. Problem is that pulumi cached it and didn’t replace the resource on changes even after a pulumi destroy which was incredibly misleading.