Re: [HTCondor-users] Combining Accounting groups and Priority factors

[Greg Thain <gthain@xxxxxxxxxxx>]

On 04/24/2018 10:10 AM, Stephen Jones wrote:
> Hi,
>
> I have a question I've wondered about for quite a while.
>
> Priority factors convert the usage of some user to a priority. A low 
> priority factor will turn high usage into a low "effective priority" 
> (where low is better). Hence users with a low priority factor will run 
> more work. I think that's right. On the other hand, accounting groups 
> assign users to a group, and an allocation can be made for that group, 
> using (e.g. GROUP_QUOTA_DYNAMIC_group_SOMEGRP =Â 0.65)Â I've read 
> somewhere that these can be used together. And looking at my site, I 
> can see they _are_ used together. That's scary. What does it all mean?
>
> The two ideas seem to be in conflict. One controls the allocation via 
> a priority factor, that works on usage over time to promote (or 
> penalise)Â certain users according to their relative recent usage. The 
> other scheme "reserves" slots using GROUP_QUOTA_DYNAMIC... so which 
> scheme (if any) takes precedence? And if none does, how does all this 
> play out?

This is a good question, and at first blush, these two mechanisms seem 
to be in conflict.

The best way to think about this is that the group quotas "go first", 
and divide up one condor pool, usually as a result of some kind of 
ownership -- e.g. group a has purchased one third of the node, and group 
b has purchased the rest. After this subdivision, if groups have more 
than one user with jobs, HTCondor will still schedule jobs from those 
users in a "fair share" manner, with the decaying user priority.

-greg