Difference: UserGuide (9 vs. 10)

Revision 102011-05-02 - MassimoSgaravatto

Line: 1 to 1
 
META TOPICPARENT name="UserDocumentation"
Line: 124 to 124
  All these commands are described in the following sections.
Deleted:
<
<
 

0.1 Submitting jobs to CREAM based CEs

Changed:
<
<
To submit jobs to CREAM based CEs, the command glite-ce-job-submit must be used. The glite-ce-job-submit command requires as input a job description file, which describes the job characteristics and requirements through the JDL (Job Description Language). A typical example of a JDL job description file is:
>
>
To submit jobs to CREAM based CEs, the command glite-ce-job-submit must be used. The glite-ce-job-submit command requires as input a job description file, which describes the job characteristics and requirements through the JDL (Job Description Language). A typical example of a JDL job description file is:
 
[
Line: 145 to 143
 ]
Changed:
<
<
Such a JDL would make the myexe executable be transferred on the remote CREAM CE and be run taking the myinput.txt file (also copied from the client node) as input. The standard streams of the job are redirected to files message.txt and error.txt, and when job completes its execution they are automatically uploaded on gsiftp://se.pd.infn.it/data/seredova.
>
>
Such a JDL would make the myexe executable be transferred on the remote CREAM CE and be run taking the myinput.txt file (also copied from the client node) as input. The standard streams of the job are redirected to files message.txt and error.txt, and when job completes its execution they are automatically uploaded on gsiftp://se.pd.infn.it/data/seredova.
  A detailed description of the available JDL attributes and of the rules for building correct JDL files is provided at http://wiki.italiangrid.org/twiki/bin/view/CREAM/JdlGuide.

Each job submitted to a CREAM based CE is given the delegated credentials of the user who submitted it. These credentials can then be used when operations requiring security support has to be performed by the job.

There are two possible options to deal with proxy delegation:

Changed:
<
<
  • asking the “automatic” delegation of the credentials during the submission operation;
>
>
  • asking the “automatic” delegation of the credentials during the submission operation;
 
  • explicitly delegating credentials, and then asking to rely on these previously delegated credentials on the actual submission operations.
Deleted:
<
<
 It is highly suggested to rely on this latter mechanism, using the same delegated proxy for multiple job submissions, instead of delegating each time a proxy. Delegating a proxy, in fact, is an operation that can require a non negligible time.

The command glite-ce-delegate-proxy is the command to be used to explicitly delegate the user credentials to a CREAM CE.

Line: 160 to 156
  The command glite-ce-delegate-proxy is the command to be used to explicitly delegate the user credentials to a CREAM CE.
Changed:
<
<
The following shows an example of job submission, performed explicitly delegating credentials. So first of all the credentials are delegated to a CREAM based CE (whose endpoint is specified with the option --endpoint (-e):
>
>
The following shows an example of job submission, performed explicitly delegating credentials. So first of all the credentials are delegated to a CREAM based CE (whose endpoint is specified with the option --endpoint ( -e):
 
> glite-ce-delegate-proxy -e cream-ce-01.pd.infn.it mydelid
Line: 293 to 285
 

0.1 Purging jobs

Changed:
<
<
A CREAM job can be monitored (via the glite-ce-job-status) even after it has completed its execution. A job gets “lost” (i.e. it is not possible to monitor or manage it anymore) only when the user who submitted it decides to explicitly clear it, or when the CREAM system administrator decides to do this purging operation. A user can purge her own jobs, using the glite-ce-job-purge command.
>
>
A CREAM job can be monitored (via the glite-ce-job-status) even after it has completed its execution. A job gets “lost” (i.e. it is not possible to monitor or manage it anymore) only when the user who submitted it decides to explicitly clear it, or when the CREAM system administrator decides to do this purging operation. A user can purge her own jobs, using the glite-ce-job-purge command.
  E.g., after having issued the command:
Line: 301 to 293
 > glite-ce-job-purge https://cream-ce-01.pd.infn.it:8443/CREAM116jbi4o0
Changed:
<
<
the specified job can’t be managed anymore (e.g. it is not possible to check its status anymore).
>
>
the specified job can’t be managed anymore (e.g. it is not possible to check its status anymore).
 

0.1 Renewing proxies

Line: 353 to 343
  In order to avoid degrading the performance of the system, the specified policy is not evaluated for each job submission, but instead it is evaluated and imposed from time to time (so it might happen that for a short time job submissions are allowed even if the specified threshold has been reached).
Changed:
<
<
CREAM “super-users” can also disable newer job submissions via the command glite-ce-disable-submission. Submissions can then be re-enabled by a CREAM “super-user” via the command glite-ce-enable-submission.
>
>
CREAM “super-users” can also disable newer job submissions via the command glite-ce-disable-submission. Submissions can then be re-enabled by a CREAM “super-user” via the command glite-ce-enable-submission.
  To check if job submissions on a specific CREAM CE are allowed, the command glite-ce-allowed-submission can be used.
Line: 418 to 403
 
  • A general configuration file. This file is looked for in /etc/glite_cream.conf

Changed:
<
<
  • A VO specific configuration file. This file is looked for in /etc//glite_cream.conf
>
>
  • A VO specific configuration file. This file is looked for in /etc/<VO> /glite_cream.conf
 
  • A user specific configuration file. This file is looked for in the following order:
    • The file specified with the --conf option of the considered command
    • The file referenced by the $GLITE_CREAM_CLIENT_CONFIG environment variable
Changed:
<
<
    • $HOME/.glite//glite_cream.conf (if the VO is defined), or $HOME/.glite/glite_cream.conf otherwise
>
>
    • $HOME/.glite/<VO> /glite_cream.conf (if the VO is defined), or $HOME/.glite/glite_cream.conf otherwise
 Each of these files is a classad containing definitions.

If the same attribute is defined in more configuration file, the definition in the user specific configuration file (if any) is considered. Likewise the definitions in the VO specific configuration file have higher priority than the ones specified in the general configuration file.

Line: 558 to 539
 
  • IDLE: the job is idle in the Local Resource Management System (LRMS).
Changed:
<
<
  • RUNNING: the job wrapper, which “encompasses” the user job, is running in the LRMS.
>
>
  • RUNNING: the job wrapper, which “encompasses” the user job, is running in the LRMS.
 
  • REALLY-RUNNING: the actual user job (the one specified as Executable in the job JDL) is running in the LRMS.
Line: 570 to 551
 
  • DONE-FAILED: the job has been executed, but some errors occurred.
Changed:
<
<
  • ABORTED: errors occurred during the “management” of the job, e.g. the submission to the LRMS abstraction layer software (BLAH) failed.
>
>
  • ABORTED: errors occurred during the “management” of the job, e.g. the submission to the LRMS abstraction layer software (BLAH) failed.
 
  • UNKNOWN: the job is an unknown status.
Deleted:
<
<
 The following figure shows the possible job states transitions.

cream_job_states.jpg

 
This site is powered by the TWiki collaboration platformCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback