search

byu-oit / handel

[Archived because BYU moved to Terraform.] Orchestrates your AWS deployments so you don't have to.
Apache License 2.0
14 stars 3 forks source link

Need a way to identify stacks that are orphaned by changes to handel.yml #386

Open bradleyreneer opened 6 years ago

bradleyreneer commented 6 years ago

To reproduce the issue, which occured with the storage-ws project:

Change project from Lambda, using an API Gateway, to Fargate. The Lambda and the API Gateway were created previously and were properly tagged. With the change to Fargate they are orphaned. However they will never be deleted, unless one goes out and manually deletes them. If the developer is not aware, or forgets, that the resources are still out there then because they are properly tagged they will never be deleted.

One possible solution is to delete the resources if they are removed from the handel.yml file, but this seems extreme and things could be deleted unintentionally. Another possible solution is to just tag the stack or resource if it is orphaned and these could be occasionally reviewed and when appropriate they could be deleted. Perhaps there is also a way to go through all our active repositories/codepipelines, check the Handel files and see if there are any resources that are not listed in the active codepipelines?

This seems important because we could accumulate resources that are properly tagged but no longer being used and this would defeat one of the purposes of our tagging.

ThatJoeMoore commented 6 years ago

The big problem with this is that it means Handel has to be stateful, which means Lots Of Work. I can't think of any way to make this happen from the Handel side of things without adding a state-storage engine (which has been discussed, but, as I said, is Lots of Work).

dsw88 commented 6 years ago

There might be some cheaper ways to at least help surface orphaned resources. For example, Handel can look at stacks with the app/env prefix and at least try to surface orphaned ones that aren't in the current Handel file, which is something we could do while still allowing Handel to be stateless.

This is principally an issue when services are being developed, since things will be changed up a lot during development. I do think this is one of the bigger issues with Handel currently, and I think it would be interesting to discuss ways to help.

yoshutch commented 6 years ago

What about handel adding tags to each CF stack that it makes to identify each stack that a specific handel file (and env) has created in the past. Then after it has completed (or before) creating/updating each current CF stack handel can check if there are stacks that were orphaned and execute a stack delete command or something like that?