Once the RPCs and futures are established, your code is no longer executed

JS/TS have a “dynamic” provider that is sent (as text) from the user side to the engine side during execution and has access to the engine and the tree of futures

Here’s an example: 1. Create a number of subnets in a VPC, each tagged with a “subnet type” that defines the routing to be used, eg internal only, NAT, or public. 2. Create routing tables for each subnet type 3. Associate the subnets with the routing tables

You can’t do step 3 by writing something like: subs = get_subnets() rts = get_routing_tables() for s in subs: aws.associate(s,rt[s.tags.subnet_type])

because you can’t execute a loop based on the get_subnets() call

Effectively all of the “get_*” calls are useless outside passing them into another Pulumi resource as an argument

So the entire purpose of Pulumi, which is to have both the power of a declarative syntax and the power of a dynamic language is lost in python.

I should be able to declare a python object that is of class Pulumi.Provider and be able to execute the code like in step 3 above

The same applies to being able to import resources from AWS by having an option to import before create. So I should be able to say something like: my_existing_vpc = aws.Vpc(attributes,options = {“import_before”create”:True})

Effectively all of the “get_*” calls are useless outside passing them into another Pulumi resource as an argument

It’s a future, you can use it like you would any other future, i.e. you can await it in

async

functions and then use them for control flow. Python does force you to acknowledge that you’ve now built an asynchronous graph and you’ll have to pass something into a Pulumi resource, but you can do whatever you want in an async function.

It’s like saying that

aiohttp

is useless because you can’t use it in a synchronous context. You can’t, it’s not how it was designed.

cc @proud-artist-4864

It’s important to think about what you give up when everything becomes synchronous. Fundamentally, Pulumi is a DAG execution engine; your program produces a DAG of resources and Pulumi does what it needs to do to make your state DAG match the DAG you expressed in your program. If your program is synchronous, each DAG node has to be resolved serially, one at a time. This is a really terrible experience, and I can say that with confidence because Pulumi used to do this and it was awful. Asynchrony allows a program to continue while Pulumi is chugging along on the DAG, and allows Pulumi to parallelize resource operations. It’s tempting to visualize how the programming model is improved by eliminating it, but you’re paying a massive cost to do so.

And, to be clear:

because you can’t execute a loop based on the get_subnets() call

You can do this: ```

Are there any companies (besides pulumi) using pulumi in production, specifically using python, and have made their experience public?

@incalculable-sundown-82514 thanks for the response, and I get that everything is asynchronous, but how do I engage my code in that asynchronous process. Your example of the “tables()” function, how do I call that from my main or equivalent? My main is executed within your engine by starting a separate python interpreter and wrapping it inside an async. If I call tables() inside my main, then all of the other RPCs will execute either before or after mine, I can’t link the tables() future into the DAG. That tables() function is actually dependent on two futures, one is the creation of all the subnets, the other is the creation of all the routing tables. When both of those dependencies are resolved is when the association needs to happen. So do I make my main or equivalent a async def main and then do an await on the tables()? How do I get my code after the tables() to execute within the DAG appropriately? When I tried to do this, what I found is that my first await happened, but then other code never executed, because by that stage, all of the RPCs in the stack of Pulumi resources had resolved so the engine thought all the work was done.

It’d be really great if Pulumi could post a python only example of using these get_ functions and linking a ComponentResource and/or CustomResource into the DAG because currently it does not appear that this is possible in the same way as it is in JS/TS.

any sane reason why service bus is under event hub in pulumi azure?

in terraform they are all under messaging resources

but in azure they are all different providers actually

hey, if pulumi destroy was stopped due to some unforeseen circumstances when will it allow to proceed with the next operation?

overall, after using pulumi in brownfield (to manage existing pulumi stacks) i find its a real nightmare

@little-river-49422 What do you mean by “unforseen circumstances”?

build agent stopped due to timeout

It should be able to resume immediately - unless the state lock still exists.

well, it doesnt let me do anything

If the state lock still exists, you may need to use

pulumi cancel

to remove the lock

same if the kubernetes is dropped, it fails to do anything with the stack