Garbage-collect orphaned stacks
See original GitHub issue❓ General Issue
The Question
cdk deploy leaves stack deployed if a stack is removed from application post deployment and cdk app is deployed again.
Steps to Reproduce
- Create a CDK app with two stacks
- Run:
cdk deploy --all
- Delete one stack from the CDK app
- Run:
cdk deploy --all
Expected Results The deleted stack is gone.
Actual Results The deleted stack exists and has been “leaked”.
i.e. the stacks are procedural rather than declarative. This doesn’t fit into a managed pipeline model as stacks will accidentally leak and have to be manually cleaned, while the behavior makes sense if you’re familiar with the implementation details of CDK, this isn’t the right developer experience.
Environment
- CDK CLI Version: 1.73.0
- Module Version:
- Node.js Version: 12.x and 15.2.0
- OS: macOS Mojave and CodeBuild Ubuntu (not used other OSes)
- Language (Version): TypeScript (4.0.7)
Other information
Issue Analytics
- State:
- Created 3 years ago
- Reactions:6
- Comments:9 (7 by maintainers)
Top Results From Across the Web
How does Garbage Collection identify orphaned objects?
The basic strategy used for garbage collection is to determine whether or not the data on the heap is reachable from the stack....
Read more >Garbage Collection - Kubernetes
When Kubernetes deletes an owner object, the dependents left behind are called orphan objects. By default, Kubernetes deletes dependent objects.
Read more >Deletion and Garbage Collection of Kubernetes Objects
Orphan : The object itself is deleted. The owned objects are “orphaned.” by removing the reference to the owner. Let's see how we...
Read more >Garbage Collection - Kubernetes - Wikimedia People
If you delete an object without deleting its dependents automatically, the dependents are said to be orphaned. Foreground cascading deletion. In ...
Read more >Why Garbage Collection if smart pointers are there
For example, the compiler must include information specifying, at every point in the code, the location of every register or stack-frame offset that...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Hi, I would like to revive this topic. In our company, we use CDK extensively and especially with CDK pipelines (we have 120+ pipelines ATM) the orphan stacks are becoming an issue.
The advantage of CDK pipeline is that once you instantiate it, you can forget about applying CDK changes - you simply push to git and changes are applied by a pipeline. However, if you add a pipeline “stage” and later remove it (or just rename it), the stage stacks will stay up and will be “orphaned”.
We tackle this by assigning a set of tags to each stack that uniquely identify the CDK app. We provide a tool to application owners that synthesizes the app and gets the list of “declared” stacks, then retrieves the “running” stacks - stacks with corresponding tags from CFN API - and deleting “running” that are not “declared”.
However, this tool needs to be run manually by application owners. Also, I believe many people must be having the same issue. Would it make sense to resolve this within CDK?
The AppRegistry idea looks interesting. Potentially, simpler approach with tagging and UUIDs would work too:
aws-cdk:app-id=<app-id>
Then, a new CLI can be provided. I can see many options to implement this, for example
cdk apply
that would deploy new/changed stacks and delete stacks that are no longer “declared”. Or simplycdk deploy --clear-orphans
. orcdk destroy --orphans-only
…@eladb what do you think? If there’s an interest, I would be happy to look into this
Can we track the App state in a dedicated “app” stack?
Edit: Sorry, I am not being clear. Make App deploy an “app” stack which then uses e.g. https://github.com/aws/aws-cdk/issues/13676#issuecomment-809674456 to track the state of the stacks included in the app. In future, the dedicated app stack can also wrap any app management features e.g. creating a resource group for the app, running periodic drift detection on the app stacks etc.