I'm new to Pulumi. I've noticed that pulumi.all is equivalent to Promise.all and .apply() is similar to .then(). What seems to be missing is an equivalent for await. That feels like a step back in time to using chained .then() statements. I've noticed I can wrap it in a promise sort of like this:

return new Promise(resolve => return pulumi.output(variable_name).apply(val => {resolve (val);})

The returned object looks correct, though Typescript seems to have lost all concept of the object types being returned. This makes me think about the AWS SDK where you can add .promise() to the end of a number of calls to work cleanly with await. I'm far from being a Typescript guru, but how difficult is it to have something similar in Pulumi?

You are exactly right in your analogies. TypeScript (really JavaScript) doesn't provide any way to offer generalized

await

syntax over other types of data. Despite the analogy, note that in Pulumi, 90%+ of the time

Output

is used quite differently than

Promise

is used in other APIs.

Outputs

are primarily data you pass from one place (the output of a resource) to another (the input of another resource), transforming the value along the way. This is different than common use of

Promise

in may JS APIs where it is used for control-flow. The result is that in common usage, you shouldn't need to use something like

await

on Outputs, and indeed if it was available it would encourage patterns that are not ideal for Pulumi (like creating resources "inside apply", which can lead to inaccurate previews).

Makes sense. My use case is configuration-driven code where I'm taking the created output information and comparing to configuration information in JSON objects. Hence the need to be able to extract the created values. For example, I create three VPCs, then subnets, and finally peering connections, each in a separate section of code. Tying together the configuration of each of these objects requires knowing the cidrBlock, VPC IDs, etc. Controlling these from JSON configuration is relatively straightforward, but I have to be able to see inside the created objects to know which ones to match up.

To first approximation - can't you just pass outputs from one resource to inputs of another (with a couple

.all.apply

s to convert a set of outputs into a single input)?

In simple cases, yes, that works just great and Pulumi knows how to order resource creation to get it all done. Where I encountered enormous difficulty was creating routes for subnets across peering links.

Got it. I'd be interested in seeing the code you ended up needing for that.

I did get it working, but I feel like it could/should be so much cleaner.

Sounds good - I’m

lukehoban

.

Bitbucket doesn't recognize your username, probably because we're in different organizations. I took a guess at your email address. Let me know if you don't get the invite.