This message was deleted.

Basically wait until the VM is finished building and a specific port is up and responding is what I’m thinking…

If you’re doing something where you’re always going to execute, you could simply create a callback that retries and do something like

instance.publicIp.apply(callback)

and handle the checking w/in the callback for instance available, waiting, retrying, etc. You could also look at something like https://github.com/pulumi/examples/blob/master/aws-ts-ec2-provisioners if you want to have slightly more complex logic that doesn’t necessarily run each time.

Ah, now scratching my head on the Python equivalent 🙂

There’s a Python example for provisioners as well: https://github.com/pulumi/examples/tree/master/aws-py-ec2-provisioners

I sidestep the issue by reworking the code to be not local-only: move the workload to the instances itself. via some sort of on-boot script. For instances that aren't isolated from the internet, that means SSM, which is pretty easy.

In my case I want to kick off a provisioner which interfaces with an API that becomes available on the host instance itself…

Sounds perfect. Have the host do the kicking off, after it finished booting.

Oh, so you are suggesting the host itself runs pulumi against itself?

No. Use pulumi to set up a boot-time script, and that script kicks off your provisioner.

I think I’m following but perhaps I am a bit caught up the last bit. “That script kicks off your provisioner.” Sorry for being dumb here, but aren’t we saying the same thing? “the host itself runs pulumi against itself” == “Use pulumi to set up a boot-time script, and that script kicks off your provisioner”?

I don't think so. I run Pulumi in CI. then it doesn't run again. The target machine (I don't want to say "host", there's a few machines that could be "host", in my mind), doesn't run Pulumi. It just runs a boot script, or cron job, or whatever. Something that finishes setting itself up, once it's ready.