The seriously cool way would be to standardize a global resource classad type and allow for _expression_ logic to have a way to directly address all resource ads that are deemed to apply to a particular slot and job.
That certainly takes it a step further. To that end: a way to put *any* type of ad in to the collector would really be interesting. So you could collect and reference anything you want and use it during matchmaking and execution decisions.
Baby steps though. :) I don't want to dream my way out this being possible.
This reminds me that the other way we address the common use case for this class of problem is with concurrency limits on jobs - but that doesn't handle slot-level use cases, only job-level ones.
Partitionable slot-level resource/concurrency limits would be a useful addition towards that goal. Then you might want to apply some feedback mechanism to make the upper bound of that partitionable slot dynamic based upon some business logic (like a global resource classad).
Ahh...it's fun to dream. In all honesty though, while it's a bit cumbersome to setup once, Startd cron jobs can handle a lot of what we're dreaming about here when it comes to slot-level concurrency controls. And once you get one set up, the rest follow pretty easily.
Regards,
- Ian
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}