This message was deleted.

The most recent iteration of this idea comes via the beta Command package: https://www.pulumi.com/registry/packages/command/api-docs/remote/command/ https://github.com/pulumi/pulumi-command

@millions-furniture-75402 I was thinking about that too, but wasn’t sure if this is suitable (i.e. will the

local.Command

be run every time the

pulumi up

is executed) or not

FWIW, the automation API can be used inline in a Pulumi plan and work with only

pulumi up

The

Command

docs are not super clear on this, in the sense that the

Command

resource is a resource in the overall graph as far as I understand, so assuming no updates are needed (i.e. nothing has changed in it or its dependencies that cause it to need to be updated), it won’t be re-executed again. An example would be if I used

Command

to set up the tunnel, and ran

pulumi up

, and then rebooted my machine, and ran

pulumi up

again (let’s say changed some

postgresql.Role

object, so it needs to be updated), will the tunnel get recreated (since it doesn’t exist locally anymore? Is my understanding wrong?

Lets say your

index.ts

looks like:

const executePlan = async (): Promise<void> => {
...
}

executePlan();

Then all your logic inside of that plan will execute using

pulumi up

including the tunnel that you want to setup.

I’m still not sure I follow (I’m also using Go, so maybe it’s just not possible there). My stack creates the VPC/subnets and then the RDS, and then I want to create a role in that RDS (or database or some other resource) using the

postgresql

provider, all in the same stack. So I don’t know ahead of time the RDS information in order to set up the tunnel, or my bastion host that I’ll use for the tunnel, etc. Does that make sense? It feels like in order to do this, I’d need to split it up into two stacks in order to be able to create the tunnel prior to running the main Pulumi program. But I could be thinking about it wrong

So I don’t know ahead of time the RDS information in order to set up the tunnel, or my bastion host that I’ll use for the tunnel, etc.

For this part, you just can apply your outputs, but then you're in the trap of putting resource declarations inside your applies

Yes, which I believe is generally disallowed/discouraged, yes?

I tried mocking up what I think it looks like based on the automation example

So this may be just my lack of familiarity of how the Automation API works in TypeScript, but isn’t non-deterministic when the actual calls to create the DB will be called (i.e. it will be done at a future point), and by the time it runs,

stopSshTunnel

might already be called? Conceptually, the way I think about it, it has to be:

startTunnel();
... run Pulumi plan ...
stopTunnel();

The above isn't using the automation API, just synchronously calling the startSshTunnel helper function inside of the apply (bad-ish practice).

Yes, though isn’t the actual call to Postgres to run

CREATE DATABASE …

going to be done asynchronously, and as such, the

stopTunnel()

call on line 58 might be called prior to that asynchronous activity happening?

Which is what I think the Pulumi Command package is attempting to do, but still in its infancy.

Yeah, in the automation API case it makes sense because the start/stop of the tunnel happens outside the actual running of the plan.

You could drop the postgres provider and do RAW SQL on a bastion? replacing the copyfile example with copying a SQL file, and executing the remote command: https://github.com/pulumi/pulumi-command#remote-provisioning-of-an-ec2-instance

Command

is promising, but I can’t tell if it’s suitable for this particular case, as I think it’s treated as a resource rather than as a procedural command 🙂

You'd also lose the diff with the apply hack. Consider it an opportunity to use something like flyway db or liquibase, maybe? Then your Command copies the migration files and runs the migration tool, and handles cases like "does this db exist?"