I mean user facing. I think ultimately, all limits should come down to asking
- What am I counting? E.g. the number of running jobs on a given queue, the number of jobs that have been started on a given queue, the number of running jobs on a given node, something else?
- Over what window am I counting? E.g. a zero length window, a 10 second window, a 2 week window?
- What is the max count I’m allowed to hit? Aka the limit.
Every one of the existing APIs can be framed in this context.
- a local limit is counting the number of running jobs on on a given node, it’s counting over a zero length window (aka an instant), and the max count is supplied by the user
- a global limit is counting the number of running jobs on on a given queue, it’s counting over a zero length window, and the max count is user supplied
- a rate limit is counting the number of jobs started in any given supplied partition (or the queue if none is supplied), it’s counting over a user supplied window length, and the max count is user supplied
I have a use case to count the number of running jobs on a given partition over a non zero length window, but I could imagine lots of other useful combinations. Off the top of my head:
- counting the number of running jobs on a given partition over a zero length window (aka a partition limit rather than a global or local limit).
- counting the number of started jobs on a given node over a non-zero length window (aka a per node rate limit)
The issue comes up in defining the combinations. E.g. what does measuring the number of jobs started over a zero length window mean? If you model time in discrete ticks, then that’s pretty easy, it’s how many jobs were started in a given tick, but if you model time as continuous, then it’s kind of a meaningless question. Imo, saying that your API is only accurate down to some fundamental tick size is pretty reasonable, and makes everything coherent. In such a world a “zero length window” really means a window that is the length of 1 tick.
