Re: [Condor-devel] group quotas are confusing

[Matthew Farrellee <matt@xxxxxxxxxx>]

Best to ask that on the other threads specifically on that topic. Good 
thing the list is low traffic, it was easy to find -

Some proposals regarding management of accounting groups and submitter names
RFC: increasing the sanity of accounting group notation

There's also a ticket somewhere too.

Let's consolidate.

Best,


matt

On 03/21/2012 08:45 AM, Ian Chesal wrote:
> Is there ever a good use case for:
>
> +AccountingGroup = "<group>"
>
> ?
>
> I don't think so.
>
> Why not catch and warn in condor_submit?
>
> - Ian
>
> ---
> Ian Chesal
>
> Cycle Computing, LLC
> Leader in Open Compute Solutions for Clouds, Servers, and Desktops
> Enterprise Condor Support and Management Tools
>
> http://www.cyclecomputing.com
> http://www.cyclecloud.com
> http://twitter.com/cyclecomputing
>
> On Wednesday, 21 March, 2012 at 8:05 AM, Matthew Farrellee wrote:
>
> > It looks bad in the manual.
> >
> > http://research.cs.wisc.edu/condor/manual/v7.7/3_4User_Priorities.html#SECTION00447000000000000000
> >
> > +AccountingGroup = "group_physics"
> >
> > disagrees with
> >
> > http://research.cs.wisc.edu/condor/manual/v7.7/3_4User_Priorities.html#SECTION00448000000000000000
> >
> > +AccountingGroup = "<group>.<subgroup>.<user>"
> >
> > Note: "<group>[.<subgroup>*].<user>" would be better.
> >
> > "Note that a job specifying a value for the AccountingGroup ClassAd
> > attribute that lacks at least one period in the specification will cause
> > the job to not be considered part of a group when negotiating, even if
> > the group name (highest within the hierarchy) has a quota. Furthermore,
> > there will be no warnings that the group quota is not in effect for the
> > job, as this syntax defines group accounting."
> >
> > This note is not as bold as it used to be.
> >
> > http://research.cs.wisc.edu/condor/manual/v7.5/3_4User_Priorities.html#SECTION00448000000000000000
> >
> > "_NOTE_: An accounting group value lacking the period will cause the job
> > to not be considered part of the group when negotiating, even if the
> > group name has a quota. Furthermore, there will be no warnings that the
> > group quota is not in effect for the job, as this syntax defines group
> > accounting."
> >
> > And given that everyone trips over this at least once, it should be even
> > more bold as a huge gotcha.
> >
> > The example disagreement possibly goes back to 6.7 manual.
> >
> > http://research.cs.wisc.edu/condor/manual/v6.7/3_5User_Priorities.html#SECTION00456000000000000000
> >
> > Best,
> >
> >
> > matt
> >
> > On 03/20/2012 03:57 PM, Lans Carstensen wrote:
> > > You need to set AccountingGroup to be "GROUPNAME.OWNER", e.g.
> > >
> > > +AccountingGroup = "nwp_few.user"
> > >
> > > -- Lans Carstensen
> > >
> > > On Tue, Mar 20, 2012 at 12:48 PM, Nathan Panike<nwp@xxxxxxxxxxx
> > > <mailto:nwp@xxxxxxxxxxx>> wrote:
> > > > I was testing out preemption, so I set the following
> > > > configuration: The idea is that I could submit some jobs in the
> > > > "nwp_few" accounting group which would then begin running, then start
> > > > some up in the "nwp_lots" accounting group, and see them preempt the
> > > > jobs in the "nwp_few" group. Unfortunately, now all I get is "Reason for
> > > > last match failure: group quota exceeded" for every job.
> > > >
> > > > What am I missing?
> > > >
> > > > Nathan Panike
> > > >
> > > > JAVA_BENCHMARK_TIME = 0
> > > > MAIL = /bin/mail
> > > > # If I disable this, I can run jobs
> > > > GROUP_NAMES = nwp_lots, nwp_few
> > > > GROUP_QUOTA_DYNAMIC_nwp_lots = 1.0
> > > > GROUP_QUOTA_DYNAMIC_nwp_few = 1.0
> > > > GROUP_PRIO_FACTOR_nwp_lots = 1.0
> > > > GROUP_PRIO_FACTOR_nwp_few = 100.0
> > > > GROUP_ACCEPT_SURPLUS = True
> > > > SLOT_TYPE_1=cpus=32
> > > > NUM_SLOTS=1
> > > > NUM_SLOTS_TYPE_1 = 1
> > > > SLOT_TYPE_1_PARTITIONABLE=true
> > > > NUM_CPUS = 32
> > > > PREEMPTION_REQUIREMENTS = True
> > > >
> > > > A submit file looks like
> > > >
> > > > executable = /bin/sleep
> > > > arguments = 300
> > > > universe = vanilla
> > > > output = dslots.$(cluster).$(process).out
> > > > log = dslots.log
> > > > +AccountingGroup = "nwp_few"
> > > > error = dslots.$(cluster).$(process).err
> > > > request_memory = 4
> > > > request_cpus = 32
> > > > queue
> > > > request_cpus = 32
> > > > queue
> > > > request_cpus = 32
> > > > queue
> > > > request_cpus = 32
> > > > queue
> > > >
> > > > and another submit file looks like
> > > >
> > > > executable = 1281.sh <http://1281.sh>
> > > > arguments = $(cluster)
> > > > output = 1281.$(cluster).$(process).out
> > > > error = 1281.$(cluster).$(process).err
> > > > log = 1281.log
> > > > +AccountingGroup = "nwp_lots"
> > > > request_cpus = 1
> > > > request_memory = 10
> > > > queue
> > > > _______________________________________________
> > > > Condor-devel mailing list
> > > > Condor-devel@xxxxxxxxxxx <mailto:Condor-devel@xxxxxxxxxxx>
> > > > https://lists.cs.wisc.edu/mailman/listinfo/condor-devel
> > > _______________________________________________
> > > Condor-devel mailing list
> > > Condor-devel@xxxxxxxxxxx <mailto:Condor-devel@xxxxxxxxxxx>
> > > https://lists.cs.wisc.edu/mailman/listinfo/condor-devel
> >
> > _______________________________________________
> > Condor-devel mailing list
> > Condor-devel@xxxxxxxxxxx <mailto:Condor-devel@xxxxxxxxxxx>
> > https://lists.cs.wisc.edu/mailman/listinfo/condor-devel