Re: [Condor-devel] Condor 7.6.1 timeline?

[Erik Erlandson <eerlands@xxxxxxxxxx>]

On Thu, 2011-05-19 at 16:17 -0500, Brian Bockelman wrote:

> The naive approach for allocating surplus would be:
> 1) Allocate static groups until they hit their original limits or run out of requests.
> 2) Allocate dynamic groups the remainder or until they run out of requests.
> 3) Allocate the remainder to static groups until they run out of requests
>
> Is there anything wrong with that approach?

I think that is a plausible definition -- one issue we ran up against is that the space of possible definitions for "fair distribution of surplus" is large, and our goal was to pick a definition that (a) didn't straight-up explode on any corner cases, and (b) was logically defensible.  My rationale for the current surplus sharing was that a single unified algorithm could be applied to surplus allocation, and it was based on the assigned quota -- which is in a unified 'resource space' regardless of whether the original configured quota was dynamic or static.  (For better or worse, I made many of these choices from the point of view that use cases involving static quotas were the minority out in the wild.)

In the near term, some kind of methodology for configuring static group quotas for maximum stability will be useful.  For a configuration involving both static and dynamic quotas, it would be good, if possible, to keep all groups with dynamic quotas under one subtree, for example:

GROUP_NAMES = a, b, c, c.c1, c.c2

# all groups with static quotas
GROUP_QUOTA_a = 100
GROUP_QUOTA_b = 100

# all dynamic quota groups under single sub-tree:
GROUP_QUOTA_DYNAMIC_c = 1.0
GROUP_QUOTA_DYNAMIC_c.c1 = 0.5
GROUP_QUOTA_DYNAMIC_c.c2 = 0.5

This would keep the numeric behavior stable:  the quotas assigned to dynamic-quota groups goes to zero only if the available remainder after all static groups in the configuration is zero.


> It seems strange to handle static/dynamic separately in the initial allocation, then handle them as if they were identical in the surplus allocation.
>
> > 
> > I cannot access red-condor.unl.edu -- If you can email me your hierarchical acct group config, I can think about an approach to addressing your goals.  At the moment your use case for mixed static/dynamic still isn't clear to me. 
>
> Actually, we were able to avoid it by removing unnecessary groups, making the "top level" sufficiently large.  So, problem avoided for now.
>
> Brian
>
>
> FWIW - I can access red-condor.unl.edu from my home cable modem... maybe a firewall on your side?
> brian-bockelmans-macbook-pro-3:~ brian$ condor_config_val -pool red-condor.unl.edu -name red-condor.unl.edu GROUP_NAMES
> cms, cms.prod, cms.lcgadmin, cms.other, cms.other.prio, cms.other.user, cms.other.user.nonus, cms.other.user.us, cms.other.user.t3, other, other.hcc
>
>
> > E
> > 
> > 
> > 
> > _______________________________________________
> > Condor-devel mailing list
> > Condor-devel@xxxxxxxxxxx
> > https://lists.cs.wisc.edu/mailman/listinfo/condor-devel