How does garbage collection get enforced?
See original GitHub issueI recently re-purposed a use case policy described in EBS - Garbage Collect Unattached Volumes using the security-group resource and have questions on its usage.
Question 1 : marked-for-op Delete Enforcement When I run my policy, I can see my unused security groups get tagged with key:value pair of “maid-status:Resource does not meet policy: delete@2018/05/12”
How does the deletion get enforced? How does one verify?
I have set my policy to delete after 1 day, but my marked security-groups are still present.
Question 2: marked-for-op Delete Action Granularity Is there an option to set deletion in minutes/hours?
For example, is this supported:
actions:
- type: mark-for-op
op: delete
minutes: 1
Note: I would only use this type of granularity for testing or when I was highly confident of the consequences.
Question 3: marked-for-op Delete Action Window If my policy is run multiple times say by (1) a cron job running on an EC2 instance or (2) as a lambda with a CloudWatch scheduled event source (eg: fixed rate of min/hours/days or cron), or (3) manually from the terminal and my delete action window was set to 1 day, does this mean my 1 day window gets reset every time the policy is run?
Question 4: marked-for-op Delete Action General Usage How is the marked-for-op delete action used in practice? Do users run their policies manually, periodically, and/or scheduled? When run periodically or scheduled, how does one prevent the action window from getting reset after being tagged for deletion? Conversely, how does one override the action window to force it to reset?
Sorry for the noob questions. I’m starting to get a hang of this but still need some help.
This is my present policy as reference:
unused-security-group-cleanup.yml
policies: - name: mark-unused-security-groups-for-deletion resource: security-group description: | Mark unused security groups for deletion in X days. A mark is a tag that gets created for each unused security group. The key/value pair takes on the following attributes: key = maid_status value = 'Resource does not meet policy: delete@year/month/day' filters: - unused - type: value key: GroupName op: regex value: .*launch-wizard.* actions: - type: mark-for-op op: delete days: 1 - name: delete-marked-security-groups resource: security-group description: | Delete security groups marked for deletion filters: - type: marked-for-op op: delete actions: - delete - type: notify template: sgroup-notify.html template_format: 'html' priority_header: '5' subject: 'CloudCustodian: Unused Security Groups' to: - email@address.com owner_absent_contact: - emaill@address.com transport: type: sqs queue: https://sqs.us-east-1.amazonaws.com/1234567890/sandbox
Issue Analytics
- State:
- Created 5 years ago
- Comments:10 (4 by maintainers)
Top GitHub Comments
Thanks for answers and the great explanation regarding how the mark-for-op and marked-for-op are implemented.
Now I get it! 👍
As a suggestion, I recommend updating the use case example so the policies visually appear as separate files.
As a new user, I blindly copied/pasted the example and treated everything as a single policy and expected Cloud Custodian to magically take care of my intent – hence the confusion that ensued. Now I’m better informed and won’t cross that bridge again.
Now…back to my use case.
Based on my new understanding of the mark-for-op and marked-for op, I was able to make progress by separating my policy and running them separately.
It appears I can set the days to “0” then run my marked-for-op delete policy separately without any issues. It works great and as expected! 👍
I also observed that it deleted sgroups that were marked with dates prior to today.
If I didn’t want that behavior, is there anyway to scope the blast radius so actions are only taken on the date/time specified?
Thanks again for the great support. Loving this product.
Hi,
Is there any schema written for deleting all the resources in the AWS account?
Looking forward your responses.