That's perfect, thank you

Hope that was clear

For some things, apply will work. I hope this is sufficient for what you want to do, Ed. We also do plan to support event hooks for pre/post operations, like preUpdate, postDelete, etc. This is tracked by https://github.com/pulumi/pulumi/issues/1691 Eager to hear whether you're successful with just apply here or if you need something richer. We might be able to get something working with dynamic providers if you do (https://github.com/pulumi/pulumi/blob/master/sdk/nodejs/dynamic/index.ts).

I can't...find...

apply

?

Like, maybe I'm totally missing it, but I cannot find

apply

on

aws.ec2.Instance

And tbh even if I use that won't it then do its thing during a preview? That seems bad

#1691 seems pretty important to actually using this in anger

I think Alex probably meant hanging this off its

id

field, e.g.

let vm = new aws.ec2.Instance(...);
vm.id.apply(_ => {
    // side-effectful code here
});

The apply body actually does not run during previews, because the value of the ID isn't yet known. This is definitely a bit of an abuse of

apply

, for sure, since it's meant to produce dataflow values that capture dependencies. And it will run on subsequent updates, not just the initial create, which for a lot of VM config scenarios won't work right. It can work for limited scenarios, though. Agree 100%, #1691 is going to be important for anything more sophisticated than "do this once during update."

Ah, okay, I see. That's clever

A lot of this right now is a bit "bootstrap the world" so I'm trying to figure out the best way to organize the steps involved; something like that would help quite a bit

Might have to break this into multiple programs, which is a bummer but expected

(even with pre/post events)

The way my own local maximum, https://github.com/eropple/auster, works is that it runs a set of CloudFormation templates, in order, with the expectation that pre/post steps occur around those templates; I was hoping that, with something a little more programmatic, I could more reasonably wire it into a single program, but that might be unwise

You might be interested to check out the Ruby on Rails example, if you haven't seen it. This is just a sample so not everything works, but it demonstrates using a subset of the CloudInit-style VM initialization that CloudFormation supports: https://github.com/pulumi/examples/blob/master/aws-ts-ruby-on-rails/index.ts This still doesn't support the synchronization with completion, however, a la

cfn-init

and signals.

Yeah, I have hacked something similar together with Terraform in the past

Not having the CFN metadata service really makes life harder, but it's unavoidable

Couldn't you just create a Component to most of this?

to do *

At the cost of significantly increased complexity, sure.

okie dokie 🙂

I need to keep things at least mostly comprehensible to my dev team once this rolls out. Minimal custom magic is good.

I hear yea, Don't take my Okie Dokie in a bad way

Not everyones situation is the same

I did not know about

pcloudinit

though and now I owe Joe a beer

It is woefully incomplete.

Might be a little mislabeled though

It's more cfninit than cloudinit, yeah?

Yeah, it sort of morphed in situ. I should probably rename it.