Certificates deletion grace period

[AlecTroemel]

Currently, if certificates are managing by ingress resources, the cert is deleted right when the ingress is (or whenever the sync-interval is). It would be great if you could set an optional Grace-period for cert deletion. The use-case in mind is when doing local development where api resources are being created and deleted many times (in my case through helm charts), the grace period could be set so that you're not hitting the lets-encrypt rate limit because of cert recreation. Thoughts?

[donspaulding]

Looking at the code, it seems this would most likely be handled by gcSecrets. However, that's a reconciliation loop that has no concept of the time at which a secret originally became "unused".

That being said, if k-c-m could store off some timestamp on the secret itself in the K8S API the first time the gcSecrets reconciliation loop determined that it was unused, perhaps it could pay attention to that later?

I'm new to this codebase, so I may be way off. But I work with @AlecTroemel and we are both interested in seeing this feature make it into k-c-m. I'd be willing to put some time into figuring this out, if the project maintainers think it's a valuable feature to add.

[luna-duclos]

This would be valueable. The approach you suggest is indeed valid for this, and I would merge a PR with this.

[whereisaaron]

The grace period for deletion would be a sensible feature. If you can work out a clean implementation that's great.

The deleting and recreating Secrets is not actually much of an issue. The k-c-m database caches the certificate, so it doesn't re-request or re-issue the certificate. But I agree, the Secret deletion/recreation is often unnecessary, just due to the default fast sync speed.

You can increase the sync-interval to several minutes or an hour even. Everything that needs to be timely is event driven. The sync is only for garbage collection and picking up on any missed events (which seldom happens while k-c-m is running).