On Sat, 2011-05-21 at 11:21 -0500, Brian Bockelman wrote:
I wanted to give you more background on our use case. We have basically five categories of users:
1) CMS users from Nebraska (a strict subset of 2). 100 additional guaranteed slots.
2) CMS users from the US (a strict subset of 3). No additional guaranteed slots.
3) CMS users. 500 slots.
4) CMS production. 500 slots.
5) Everyone else. 10% of the cluster.
When there is surplus (and there is, as the cluster is about 2000 cores), we want it allocated in priority order. I.e., a slot should go to a Nebraska user before a US user, a US user before a generic CMS user, etc.
The only way I could figure out how to implement this was with mixing static and dynamic groups, as the static group will stay the same and the dynamic group will expand. Even this is an approximation because I don't think I have handled the USCMS-as-a-subset-of-CMS situation handled correctly. I've been thinking lately that maybe there's something clever possible by assigning jobs to non-leaf nodes in the hierarchy, but haven't been able to solve it.
Hi Brian,
I think the behavior you are after would be best addressed with submitter and/or group priority factors. The concepts of group quotas and submitter priorities are orthogonal: group quotas do not control the priority of slot assignment. For more information on group priority factors, you can look here:
http://www.cs.wisc.edu/condor/manual/v7.6/3_3Configuration.html#19692
One outstanding issue with the current incarnation of HGQ is that group quotas do not play with priorities as well as they could. Improving this is fairly high on my to-do list for the current release cycle, and your use case throws some additional weight behind that.
