[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Condor-users] group <none> appeared after upgrade from 7.4.3 to 7.6.2



I think it's fine as long as you GROUP_DYNAMIC_MACH_CONSTRAINT to make sure the quota calculations are getting the correct number of real slots for jobs.

There are certainly windows where the <none> group may get slots in front of the admin defined groups (which I would argue is a bug) if your cluster has a bunch of slots free (not many <none> jobs running so that starvation number is low) but I don't think that matters much as it should pretty quickly catch up the real groups if there are lots of free slots. It doesn't matter if the <none> jobs get slots first if the real group quota jobs are going to get them in the next few cycles. Once a cluster is full, it should work as desired.

Thanks again,

joe

On 10/19/2011 11:49 AM, Dan Bradley wrote:

Yes, priority factor only influences allocation of resources within a group.

As for how to configure priority factors: if you set GROUP_PRIO_FACTOR for all
other groups, I believe the default priority factory for users in the <none>
group can be set with DEFAULT_PRIO_FACTOR and/or REMOTE_PRIO_FACTOR, depending
on how ACCOUNTANT_LOCAL_DOMAIN is configured.

I agree that it is worth considering adding some mechanism to Condor whereby the
<none> group is considered last in the negotiation cycle. This would more
closely mimic the old behavior prior to 7.5.6. Of course, it may not always be
desired to starve the <none> group when there is contention for a subset of the
pool, so this would probably need to be a configurable option. Ugh ... more knobs.

--Dan