Exclude resources with owner references?

[fad3t]

Good afternoon everyone!

I'm using kor from time to time, and I find it really useful - thx for sharing it with us!

I'm wondering if there's a way to exclude resources that have owner references set -- because they belong to other type of resources.
For example CNPG (Cloud Native PGSQL) -- creating a new Cluster triggers the creation of secrets holding the superuser credentials, the replication key, .. and they shouldn't be deleted, even if they're not actively used by a pod.
Those resources have the ownerReferences field set, and I was thinking it'd be great if we could filter them out -- but from what I see, this is currently not possible.
Any suggestion?
Thanks!

[yonahd]

Hi @fad3t
Happy to hear you are enjoying kor!

Regarding your question, we have a couple ways to work around this issue.

First is https://github.com/yonahd/kor?tab=readme-ov-file#ignore-resources
By adding this label kor will always consider the resource used

Second option would be to exclude the resources based off labels using the flag

--exclude-labels

Let me know if this solves the issue

[fad3t]

Hi @yonahd, thx for your reply. I don't think using labels would work because i) those resources don't have specific labels I could use to exclude them and ii) it's not always possible to pass labels that would then be propagated down to those "children" resources.

[doronkg]

Would you like to see a flag to exclude such resources even if they are actually unused?

For example:

--ignore-owner-references

That way, even if the resource is considered as unused, as long as it has ownerReferences it'll be ignored by kor.

[fad3t]

Hello @doronkg that would be an option, yes. For now a simple on/off would do I think, maybe in the future people might want to filter on specific owner references - but I don't have such use case for now, so the simple form should be enough.

[yonahd]

Great!
So I think this can be a nice feature. Let me see if we can turn this into a feature request

[yonahd]

@fad3t I think this can be closed as it's addressed by #467

[fad3t]

Great, you guys are awesome :) Thanks!