Hello - I have a question regarding stack reference dependencies. Here’s our use case: We have a project that creates a VPC and an EKS cluster along with some common resources. We have a second project that references the first projects outputs to create deployments, etc. That works great.
I can get into a weird state, however, if I try to delete the cluster stack without first deleting stacks that are dependant on it.
So, what I’d like to do is: When I deploy a child stack, I want to tell the parent stack that it now has a dependency. This could, hopefully, let me raise an error if I try to delete the parent stack without first deleting the child stacks.
Is anyone aware of a way a child stack can inject either configuration or state into a parent stack? Seems a bit odd, I realise, so if there’s a better way of handling this on a self-managed object storage backend, I’d love some ideas.
05/26/2022, 2:29 AM
It's not odd, and it's fairly common. I don't think there's a built-in way to handle it, and that's to be expected, I think. Even if it's not deliberate, it would probably be a deliberate design decision not to change it. Parent projects should not have reference to child projects, even to protect against this sort of dependency-misalignment.
Instead, you should design safety into the parent stack. The easiest way to do this in Pulumi is to set deletion protection to all shared resources. Things like VPC, subnets, RDS instances all qualify for this.
And you should add documentation to those deletion protection opts to explain what child projects are dependent on this, so that anyone who goes into the code to remove the protection will see it and can check that all the child projects have had all their stacks destroyed.
If you're using automation api, you could easily wrap the parent stack in checks for child stack resources.. that would safer, and wouldn't really be breaking encapsulation...
05/26/2022, 2:42 AM
Thanks- that’s good advice. I’ll have a look through the stack and start adding the deletion protection. We’re on our way to the automation API- we’re using it in some test workflows, and it’s pretty nice. Good idea to move this concern there when we get more mature.