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

Re: [Condor-users] No matches being made



On Mon, 23 Jan 2006, Alan De Smet wrote:

Steven Timm <timm@xxxxxxxx> wrote:
The goal of the wrapper is to add the AccountingGroup to all
jobs that are submitted, and have that AccountingGroup be based on
the gid of that user within my cluster.
It's adding the classad correctly but it seems to be interfering
with jobs that are submitted via condor-G, destined for this cluster
or for elsewhere.
...
So  question one--how to wrap condor_submit in such a way that
AccountingGroup can be attached to Vanilla universe jobs
(whether sent to the cluster inbound from the GRAM interface or submitted
locally) but not break submission of Globus (gt2) universe jobs outbound?
Or do I have some other problem here?

So taking a quick look at how Condor handles this case, yes, it
appears that AccountingGroup can confuse grid jobs.  I'm going to
look deeper into it and see about getting it to do the Right
Thing (which is probably just ignoring the AccountingGroup in
this case).

As you note, the immediate answer is probably to just avoid
adding the AccountingGroup to grid jobs.  I can't suggest any
trivial fixes beyond the obvious, perhaps just direct local user
to call condor_submit_real directly, or modify your condor_submit
to check for a universe of grid or globus, or modify the Globus
submit scripts (From memory:
$GLOBUS_LOCATION/lib/Perl/Globus/GRAM/Condor.pm) to add the
desired details.


I was able to modify my shell script. Now it basically parses
the arguments to condor_submit, then greps the submit file to see
if Universe = Vanilla is specified--if so it adds the Accounting Group,
if it is a Globus/gt2 universe it does not.
In this form the wrapper does what I want it to do, and outbound globus/
gt2 universe jobs get submitted correctly by the schedd, and I
still have the AccountingGroup assigned everywhere I needed.

However, it doesn't explain the other problem I had over
the weekend, where I had jobs that were not outbound globus/gt2 jobs
that were also getting held with errors of no match found.
If anyone has ideas on what might have been causing that, ideas are
welcome.

Some Condor staff have suggested that eventually we might
get a new feature whereby we can configure which users ought
to be in which AccountingGroup somewhere in the config files.
Would be nice to have that because right now there is still nothing
stopping a grid user from putting a different AccountingGroup in
his class ad and joining an AccountingGroup with a higher batch slot
quota.

Steve Timm


--
Alan De Smet                              Condor Project Research
adesmet@xxxxxxxxxxx                 http://www.condorproject.org/
_______________________________________________
Condor-users mailing list
Condor-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/condor-users