search

aws-iot-builder-tools / aws-greengrass-provisioner

Simplifies provisioning Greengrass Cores and building Greengrass Lambda functions
Apache License 2.0
54 stars 15 forks source link

Clean up resources at completion of labs #1

Closed sverze closed 5 years ago

sverze commented 5 years ago

Being OCD I would like my account cleaned up of any resources that were created during the lab(s) that are not cleaned up when deleting the cloud formation stack(s).

timmattison commented 5 years ago

I will look at porting some code I have from another project into this project for this purpose. Stay tuned.

timmattison commented 5 years ago

@sverze for clarity, do you see this option as cleaning up the Greengrass resources, Greengrass + IoT (things, certs, policies), or Greengrass + IoT + Lambda?

I'm looking at the last option so it is a full cleanup but I want to make sure I'm not missing anything and end up having it go overboard.

Sandmania commented 5 years ago

I'd say anything and everything created by GGP so that would include the lambda function(s), too. Lets say I just ran GGP -a ARM32 -g ggptestgroup -d deployments/python-hello-world.conf --script and were to run something along the lines of GGP --clean -g ggptestgroup afterwards, I would expect it to remove everything it previously generated.

timmattison commented 5 years ago

Good feedback and I agree. I'm trying to figure out the error handling of this and so far I think that if some resource can't be deleted it should be skipped and it should do as much cleanup as possible.

--clean gets tricky for two reasons. First, --clean -g ggptestgroup doesn't let the system know what deployment was used so that needs to be figured out from the configuration in the cloud. Second, it doesn't know if a local Docker container or EC2 instance was used.

In both of these cases I believe the best approach is to read the current config in the cloud and then delete all functions that are referenced in its config. It should then kill/rm any local Docker container with the group name. Finally, it should terminate any EC2 instances tagged with the group name.

Now, the edge case that I'm concerned about is what if someone adds another Lambda function to the group with --update-group but that Lambda function is shared with other cores. In the first incarnation of this I'm only going to delete Lambda functions that start with the group name to avoid that being an issue.

timmattison commented 5 years ago

Also, I think that I'm going to call this --delete-group instead of clean just so that it's clear that it is destructive.

Sandmania commented 5 years ago

--delete-deployment might be a good candidate, as well. The Concepts and Getting started documents seem to use that as an umbrella term for everything being created. Also the script is called deploy.sh. I think --delete-group might give the false impression that only the greengrass group is deleted. Then again, deployment is a concept in greengrass, too...

timmattison commented 5 years ago

The naming of deployments was probably a bad choice on my part. I'll consider changing that.

In the meantime I'm working on the guts of this so there's forward progress but it's not visible yet.

Still on the fence about how the command should be named so people know how destructive it is. Maybe there's a preview of what will be removed first, and then it prompts the user to confirm. What do you think?

Sandmania commented 5 years ago

Making the cleanup proses more 'talkative' / verbose might be a good idea. While confirming thing to are being removed, it could also be indicated to the user that there are some edge cases that might not be covered just yet (like the shared lambda functions).

timmattison commented 5 years ago

I know this has sat for a while but there is hopefully something coming in the next few weeks to address this. It will be part of a separate project but it should meet your needs. Ping me here if your requirements have changed and once this other project is ready we can move any differences over to an issue there. I'll leave this open until then.

QuinnCiccoretti commented 5 years ago

What's the status of this enhancement? I'm looking for some way to automate deletion of anything created by the provisioner in AWS IoT/Greengrass.

timmattison commented 5 years ago

Finally got the time to get to this. There is a project that was open sourced today that allows you to clean up resources related to Greengrass deployments. Today it specifically cleans up a single account and all cores but could be updated to include a new feature like that.

The project - https://github.com/awslabs/aws-iot-client

Let's move this discussion over there.

timmattison commented 5 years ago

No docs yet unfortunately, we're working on that.

QuinnCiccoretti commented 4 years ago

@sverze @Sandmania Recently open-sourced a nice script for doing this. The repo is here: https://github.com/QuinnCiccoretti/greengrass-util Install the requirements, and run this command:

python3 bulk.py delete-group group_name_to_delete

It will redundantly delete everything associated with that group, including detaching certificates and policies. It will also function correctly with orphaned core definitions and other lingering resources (provided they follow the provisioners naming convention, and you pass in the name of the group they once belonged to). I highly recommend looking at the source, it is complicated but easy to see where each step happens.