Hello people, happy to be here, hope you doing gre...
# automation-api
h
Hello people, happy to be here, hope you doing great ! I'm currently getting into pulumi automation API with TypeScript I'm writing a program that aim at deploying multiple stack across multiple projects that I plan to add to our CI/CD. I have two questions. Question1: I have no issue running de up part for multiple stacks. But how can I manage the depedency so that when I want to destroy them all I don't have to reimplement the inverse dependency logic between them every time ? (Kinda like I would do with a
terragrunt run-all apply
or
terragrunt run-all destroy
) I feel like it should be a native behaviour of Pulumi as the complexity tend to grow exponentially with the number of stacks. The only related topic i could find is https://github.com/pulumi/pulumi/issues/5462 (could not find the follow up) but that's about is.
e
We've been thinking about this internally. We think it's solvable with stack references but needs a lot of work to properly enable.
h
Damn would really be nice feature for Pulumi pulumi logo That's really something missing from how I would like to use my IaC: Separate my work into different projects (for separation of concerns, collaboration on the same repo made easier, rate of change and blast radius) And be able to run all my projects/stacks in the proper dependency order every time (to avoid drift from unintended changes outside of IaC and tearing whole environments up and down at night and in the morning or most importantly in case of a DRP).
Thanks for the answer ! Any idea on how this fits into your roadmap ? Can we help ? 😮
e
Still early thinking on it at the moment, but it's got the CEOs interest so it'll probably happen at some point.
h
Just thinking out loud here, but seemingly you could just loop all the stacks twice calling destroy? First time through, so things might fail to destroy because they still contain objects that are from other stacks but on the second pass the contained stacks would have been destroyed already.
h
Does not really work if i have multiple stack dependencies (s1 => s2 => s3 => ...). I might have to run it multiple times, until there are no more ressources left. It does not scale well. Plus, I have learned through experience not to rely too much on the TF Providers or CSP apis to be good on managing resources lifecycle that are not destroyed in the proper order...
I was thinking running a list of resource stacks in on way for the up and in the other way for the destroy. But it's not very efficient in term of async without having something too complicated ^^'
h
Yeah, seems like a complex set up. In your shoes, I might try using a naming convention and then you could destroy all of the "inner3-XYZ" stacks and then all of the "inner2-XYZ" stacks. Just for my curiousity what necessitates such deep nesting of stacks?
h
Though about that as well, I might give it a try actually, I will keep you posted. I'm not going deeper than 3 atm but a lot at the second and third level. But one exemple would be:
10_base network with aws transit gw
->
20_vpn config
->
20_firewall
->
20_app network
->
30_eks cluster
->
20_app network
->
s3
Thanks !
h
Oh wow.... This is my first pulumi project, but we'd put that all together in a single stack possibly using Component Resources to show the groupings.