Additional rule matching with janitor/ttl?

[CookieComputing]

Are there any plans on adding additional rule matching (e.g. whitelisting a specific instance of a resource, etc.) alongside the janitor/ttl annotation, or is the design based on the premise that if the resource is included and there is an annotation, it will be removed? Or is this the case that rule matching will always be used in the situation when an annotation isn't marked?

[hjacobs]

@CookieComputing can you describe your use case? I don't fully understand what you are trying to achieve/solve.

[CookieComputing]

I was wondering about the case where a user mistakenly applies the janitor/ttl annotation to one of their resources. If a pod or PVC, for example, was annotated by a script that a user had left running accidentally, is there any fall back mechanism for them? Or should extreme caution with the annotation be exercised?

[hjacobs]

@CookieComputing I think it depends on the use case: "with great power comes great responsibility".
For me there are two different topics here:

1. "Human error": The impact of kube-janitor can be limited by restricting it by resources or namespaces. There are other "dangerous" things you can do with full access to the Kubernetes API, so I would generally recommend production changes only via git and CI/CD (or even GitOps).
2. Additional conditions together with TTL annotation: I could imagine use cases where a user wants to express something like "apply TTL of X to this resource, but only if it has state Y" (e.g. to only delete Pods which are not in "Running" phase anymore)