I have a scenario where I want the pods of some specific users to run on specific worker nodes by using the typical native scheduling methods of k8s.
Those user pods though must not be interrupted by the cull service, they must run indefinitely once the users have spawned them and unless they manually stop them.
Is it possible to configure the cull service in way that ignores the user pods that are running on this node?
manics
November 21, 2024, 1:54pm
2
It’s not possible with the current idle-culler. There are ongoing discussions about how to make it more customisable
opened 08:57AM - 15 Jul 20 UTC
enhancement
Now that the culler is installable, a question is: how should the culler be cust… omized? Previously, it was via making a copy and modifying it. Now, there is one blessed, easy to install version - what happens to others?
In one way, I am very happy it's a separate repo now, so that it's straightforward (possibly not easy, though) to maintain a long-running fork. On the other hand, it means now I need to actually think about what's the best way, and coordinate...
### Alternative options
Based on really quick thinking:
1. Do nothing, blessed version is installable, other versions installed manually via `pip install https://...` from own github fork in special branch.
2. Encourage different custom situations to be submitted upstream. But, then we need to decide what is worth accepting, and then we get into a huge mess where we decide an API without much planning (e.g. in my case, I use a `culltime` element in the spawner state to decide when it can be culled.)
3. Encourage/support people to still copy/(rename) the script file when needed. Naming the script __init__.py doesn't encourage this much, but this does have a benefit that it's clear that it's a different thing. I can imagine that (1) will get confusing when the same module intentionally has different functions on different people's systems, but we can just accept that.
### Who would use this feature?
I have two hubs and they both have customized cullers. I've seen enough other issues about the culler that I imagine that others customize it, too.
### (Optional): Suggest a solution
- At least document how we suggest local customizations
- Think about what kind of customizations we would accept. e.g. new command line options=OK, things that dig into spawner state to make culling choices=not maintainable.
- I would feel happy renaming __init__.py to back to cull_idle_servers.py and importing the minimum in __init__, but I don't think that can be justified (to make cases where this is copied manually elsewhere more obvious).
I hope to make a PR soon that will demonstrate something we probably don't take.
It’s essentially a single script, so for now I think your best option is to copy the script
#!/usr/bin/env python3
"""
Monitor & Cull idle single-user servers and users
"""
import ssl
import json
import os
from datetime import datetime
from datetime import timezone
from functools import partial
try:
from urllib.parse import quote
except ImportError:
from urllib import quote
import dateutil.parser
from tornado.gen import coroutine, multi
show original
and customise it. It only uses the public JupyterHub rest API
but you’re obviously free to make calls to the Kubernetes API, or anything else, in your customised version.
1 Like