-
-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Resources without tags not filtered #212
Comments
presets:
common:
filters:
global:
- property: "tag:delete/.*"
type: "regex"
value: "true"
invert: "true" Unfortunately this is not a valid filter configuration. Filters are based on Check out the filter documentation it shows how to use the I think what you are trying to do would work as you hope, but I don't honestly know. The invert filter is very wonky. I don't really like it and have been thinking of a filter rewrite for v4, but I'm not sure yet. |
Ah! You're right... I've been messing with the config so much I couldn't see the forest from the trees. The right syntax was However, it seems that while most of the resources get filtered out properly, there are still some that aren't filtered out because they "don't support custom properties": WARN[0055] unable to get property: tag:kubernetes.io/cluster/.* component=libnuke error="*resources.LifecycleHook does not support custom properties" handler=Filter item=GracefulShutdown type=LifecycleHook
eu-central-1 - LifecycleHook - GracefulShutdown - would remove
WARN[0055] unable to get property: tag:kubernetes.io/cluster/.* component=libnuke error="*resources.CloudWatchEventsBus does not support custom properties" handler=Filter item=<event_bus> type=CloudWatchEventsBuses
eu-central-1 - CloudWatchEventsBuses - <event_bus> - would remove Is this intended or should the default behaviour be that "what cannot be filtered shouldn't be removed as long as filtering is expected"? |
Well I would say you are definitely in a unique camp here. I don't think I've seen many if any take the approach of negating the filter to look for The original tool design was delete everything, filter what you want to keep instead of tag what you want to delete and keep everything else, so your config is a bit of an anti-pattern to a degree. With respect to the |
I guess you're right that what I'm doing can be seen as an anti-pattern. The Do you think it would be worth at least as a future feature to have a flag that just filters out what cannot be filtered? If not, we can close this. If yes, I'll create a new issue to keep the conversation going. |
I've given this some thought and the current way the library is written and the tooling is written I don't see a safe and logical way to "determine" if something can be or cannot be filtered. A lot of additional logic would have to be added to determine if filters were or were not successfully applied along with their state, and this likely posses to big of a risk of breaking something bad for someone. Perhaps with more test coverage and/or a major update to libnuke something like this could be supported, but at the moment it's out of scope for me. Right now I'm trying to make updates faster, add reliability in where I can, and get updates churning out as needed and make preparations for AWS deprecating v1 of their library in 1 year from now. |
We are using aws-nuke in a similar way - we have tagged resources that are part of preview environments, and are using aws-nuke as part of the cleanup with an inverted
My current solution is to use Anyway, thanks for the for @ekristen - despite this issue, the global filtering has been quite useful. |
I've been thinking about this a lot, I suppose we can detect via |
@danalstadt glad to hear that global filtering has been useful! |
Great feature saved so many lines of code from our old config! |
Things are working as expected as of now. Closing this out. |
Version:
3.3.2
When resource filtering is in place via
tag
s, some resources aren't filtered out. For this preset:the following occur:
global - Route53ResourceRecordSet
global - IAMPolicy
global - IAMRole
global - IAMRolePolicy
global - IAMRolePolicyAttachment
regional - KMSAlias
regional - ElasticacheUserGroup
regional - ElasticacheReplicationGroup
regional - ElasticacheCacheParameterGroup
regional - ElasticacheUser
regional - S3Bucket
regional - CloudWatchAlarm
regional - LifecycleHook
Some errors which come from resources that wouldn't be deleted anyway are fine. The true problem lies where there's resources that are expected to be filtered but aren't because they do not have the right tag or do not have tags at all.
Should the default behaviour be "ignore" if a resource cannot be filtered?
The text was updated successfully, but these errors were encountered: