Hey everyone, I'm new to Pulumi and I was hoping someone could help me out with an issue I'm experiencing. I'm using the Pulumi Automation API and I'm trying to resolve the problem mentioned in https://github.com/pulumi/pulumi/issues/2309. If anyone has any insights or suggestions, I'd really appreciate it. Here's some context: I'm using the Micro-stack pattern and I have two stacks, A and B. Stack B references a stack output from A. When I initially deploy the resources, everything works fine. However, when I update a stack output from A and try to deploy it, the deployment is put on hold for an extended period. This is likely because Pulumi is having trouble deleting the resource of stack A, which is already referenced by resources from Stack B. To solve the issue, I have to deploy Stack B, which identifies a change in state and updates the resources accordingly. After B is successfully deployed, the deployment of Stack A also completes successfully. If I don't deploy Stack B, the deployment of Stack A times out and I get an error message that says "deleting subnet :1 error occurred: * deleting EC2 Subnet: DependencyViolation: The subnet 'subnet-id' has dependencies and cannot be deleted. status code: 400, request id: request-id."

I may be mistaken, but I’m not sure you’re going to be able to completely alleviate the behavior(s) you’re describing. Regardless of the tool in use (Pulumi or something else), the root issue is that the AWS API prevents you from deleting a subnet that has resources attached. If it’s necessary to delete/recreate a subnet in Stack A and resources from Stack B are using that subnet, there’s not much Pulumi can do. If I may ask, why are you using different stacks? What requirements led you to using separate stacks for A and B?

I am currently conducting a POC to assess if Micro-stacks are suitable for our needs. My objective is to test scenarios where changes in the output of a stack could impact dependent stacks. In my proof of concept, I replaced the VPC in Stack A, which I understand could cause foundational issues. Now I'm trying to determine the impact on Stack B. I'm wondering if the Automation API can help me solve this issue.

I don’t think Automation API will help unwind/untangle cloud resource dependencies, especially across stacks. If there aren’t major reasons to have resources in separate stacks (refer to https://www.pulumi.com/blog/iac-recommended-practices-structuring-pulumi-projects/ for some considerations about when to use/when not to use multiple projects), you may find that having all your resources in a single project will work better for you.

Thanks @salmon-account-74572. As of now, we are considering a monolithic structure and working out which one would work best for us.

Gotcha. If I can be of help, please feel free to contact me.