like, you keep talking about SSH, which reads to me like you're configuring VMs?

I need a jump host to get to the kube api server

oh, you're spinning up cloud VMs to bring up a kubernetes cluster?

pulumi isn't on the same network

well, a managed cluster but that also spins up instances

no wonder i'm so confused, you're crossing layers

yes 🙂

ok, absolutely break those up

those are already

I just have some infra global changes too which do need kube api access

so most of the provisioning happens in a separate downlevel stack

cluster + iam provisioning should happen in that infra stack

now I'll probably move that iam provisioning to the services stack

if it was me, and i was writing from scratch, and I use Salt to manage the cluster itself--it handles very well configuring and managing long-lived VMs, and even provides building blocks for automation, monitoring etc. I would then use pulumi to deploy applications to that fabric--it handles cloud-native service configuration very well, were you need to say "make sure this service exists" and things like on-going operational concerns are completely handled for you. That said, neither of those assumptions apply to you (you are not me, and you are not starting from scratch), and tbh I'm not sure how to get pulumi to do salt's/ansible's/puppet's job.

Does this

import

option currently exist in Pulumi or is it just planned? https://www.pulumi.com/blog/adopting-existing-cloud-resources-into-pulumi/#adopting-existing-resources

(i assume it can; i know people do it with tf)

@high-translator-22614 I actually think pulumi can handle managing vms fine, as longs as you don't make them pets

we're using container optimized os from google anyway

that's fairly immutable already

ok

so it's hard to manage anything past cloud-init basically

without replace

(i'm always skeptical about "no pets anywhere" because 1. State is a thing, and 2. eventually, somewhere, there's this one component...)

heheh yeah it's very nice 'if' you can pull it off

container optimized os only allows stateless changes to /etc, which are gone after reboot, and normal writes to /var for logs etc

everything else is a full replace

that's pretty shiny

upgrades etc

it's the default for their instances

and the kubernetes/etcd/etc servers themselves are managed?