Mailing List Archives
Authenticated access
|
|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-users] Help Confuse : Condor-G and Globus Job Type
- Date: Thu, 8 May 2008 14:51:33 +0200
- From: Jan Ploski <Jan.Ploski@xxxxxxxx>
- Subject: Re: [Condor-users] Help Confuse : Condor-G and Globus Job Type
condor-users-bounces@xxxxxxxxxxx schrieb am 05/08/2008 11:24:41 AM:
> base on that script i can make a conclusion that :
> 1. when globus job type is single | multiple, condor use vanilla
universe
> 2. when globus job type is condor, condor use standard universe
> 3. when globus job type is mpi or java, then it's undefined. Is that
true
> ? But why i didn't get any error with this job type and job executed
> normally like i execute the executable program with command "./test2" ?
i
> have set GRIDMANAGER_DEBUG = D_FULLDEBUG to get brief information.
Why not? The globusrsl stuff was altogether ignored and the default job
type 'single' was assumed.
> > I'm not sure whether the globusrsl attribute is supported for GT4
hosts.
> > You should use the globus_xml attribute, for example:
> > globus_xml = <count>4</count><jobType>mpi</jobType>
> >
>
> when i change globusrsl= (jobtype=mpi)(count=4)
> with globus_xml = <count>4</count><jobType>mpi</jobType>
>
> I get the following error as i expected
>
> 5/8 14:58:40 [26056] HoldReason = "Globus error: The jobType mpi
> feature is not available on this resource."
>
> because there is no mpi job spesification at condor.pm
>
> > Basically, Condor-G acts as a WS-GRAM client and submits an XML
document
> > with the Globus job description. This XML document is interpreted on
the
> > Globus side by a "job manager", which is an adapter implemented in
Perl,
> > responsible for submitting the local job to the local scheduler and
> > monitoring its progress afterwards. On the Condor-G side, you can
specify
> > an arbitrary fragment of XML to be appended to the XML job description
> > (see below). It could be that the Condor job manager interprets some
such
> > extensions to map to Condor job types. The answer is in the condor.pm
file
> > where you can see how the local Condor job description is pieced
together.
> >
>
> I don't know about perl programming at all. Is there any perl script
that
> can i use ? May be i can change it several to customize with my need. Or
> you have suggestion what code sould i modify in condor.pm ?
You'd have to modify condor.pm. You could use pbs.pm, which already
contains support for the 'mpi' job type, as a guide.
> i want all condor job (vanilla,java,parallel,and standard) are available
through
> condor-G
As you noticed, vanilla and standard are already implemented.
'parallel' could be implemented as Globus job type 'mpi'. (add handling
for the missing job type 'mpi' in the 'submit' subroutine)
'java' is an odd one out. I guess an acceptable solution might be to treat
'java' same as 'single', but perhaps detect that the executable is 'java'
and translate that sort of job into the Condor universe. Possibly you
could also use WS-GRAM extensions mechanism to pass through user-defined
attributes specific only to the 'java' universe:
http://www.globus.org/toolkit/docs/4.0/execution/wsgram/user-index.html#s-wsgram-user-specifyingextensions
Keep in mind that the goal of Globus is to *hide* whatever local scheduler
is operating at a particular site. Exposing such implementation details to
Globus users is counter-productive.
You can't implement any of these enhancements without Perl programming.
You could submit a request for enhancement to Globus Bugzilla, but that
would likely take months to be fulfilled.
If you are setting up Globus as a frontend to a cluster (rather than some
existing Condor pool), my suggestion would be to switch from Condor to
TORQUE/Maui on the server side.
Regards,
Jan Ploski