search

hjacobs / kube-janitor

Clean up (delete) Kubernetes resources after a configured TTL (time to live)
GNU General Public License v3.0
473 stars 40 forks source link

RFC: Remove resources based on github issue/PR/branch #45

Open jasongwartz opened 5 years ago

jasongwartz commented 5 years ago

This is a proposal for an additional feature, so I wanted to get feedback on the idea before starting on an implementation.

Our use of kube-janitor at Ecosia is as follows: we create a QA/review environment as a k8s namespace for every PR, and after a TTL has been reached (eg. 7 days), we delete the namespace. We would rather automatically delete the namespace based on the PR status change (eg. closed or merged), and we’ve tried a number of techniques for this (CI on the merge commit, github actions, etc) and none are particularly consistent or clean, yet.

It occurred to me the other day that for our use-case, kube-janitor could have a different kind of annotation, eg janitor/github-pr or janitor/github-branch, that would use the github API to check if the PR is open, or the branch exists, and remove the annotated resource when that condition are no longer met. In summary, if the annotation janitor/github-pr: “ecosia/example-repo/101” existed, kube-janitor would use the github api to check if the PR number 101 on the repo ‘ecosia/example-repo’ was still in ‘open’ status.

Please let me know if this is a feature you’d be willing to include and if so, I can try, sometime in the near future, to take a crack at an implementation.

Cheers! 🙂

hjacobs commented 5 years ago

I think the use case makes sense, but I would try to keep GitHub and its API out of kube-janitor. I actually have a similar scenario (but without involving GitHub) to check conditions externally, so we could think of some hook mechanism, e.g. by passing a Python function to do whatever external check.

jasongwartz commented 5 years ago

@hjacobs sure, a plugin system would be fine for my case. Do you have an idea of how that would be managed/configured?

hjacobs commented 5 years ago

@jasongwartz I imagine something similar like the auth hook here to validate users or similar: https://kube-web-view.readthedocs.io/en/latest/oauth2.html

jasongwartz commented 5 years ago

That makes sense to me. I guess users could save the function body in a configmap and volume mount it in. I can take a look at your implementation in kube-web-view and attempt a similar technique - are you happy to see a PR or would you rather implement yourself?

hjacobs commented 5 years ago

@jasongwartz happy to see a PR, please note that I won't be responsive in the next weeks :beach_umbrella:

asoni90 commented 4 years ago

We have the same use case. We are using skaffold to provision ephemeral environment as namespace based on PR. We are currently using kube-janitor to delete dangling resources not removed by skaffold or if developer forgets to delete the environment. Also, it would be great if kube-janitor can track the helm charts and delete them as well.

hjacobs commented 4 years ago

Resource hooks are now implemented, so this feature could be implemented without changing kube-janitor itself: https://github.com/hjacobs/kube-janitor/pull/64

jasongwartz commented 4 years ago

Great! Thanks for the update, @hjacobs :tada:

hjacobs commented 4 years ago

I'll keep this issue open, because an example hook for GitHub PRs would be nice to have :smile: