Difference: UserGuideEMI2 (9 vs. 10)

Revision 102012-03-21 - AlviseDorigo

Line: 1 to 1
 
META TOPICPARENT name="UserDocumentation"

CREAM User's Guide for EMI-2

Changed:
<
<

1 CREAM Command Line Interface Guide

>
>

CREAM Command Line Interface Guide

  This section briefly explains the sequence of operations to be performed by a user to submit and then manage jobs on CREAM based CEs, referring to the C++ Command Line Interface (CLI).
Changed:
<
<

0.1 Before starting: get your user proxy

>
>

Before starting: get your user proxy

  Before using any of the CREAM client commands, it is necessary to have a valid proxy credential available on the client machine. You can create it using the voms-proxy-init command. If you already have a valid proxy available on your machine just make the X509_USER_PROXY environment variable point to it.
Line: 62 to 62
 uri : voms2.hellasgrid.gr:15004
Changed:
<
<

0.1 CREAM CLI commands

>
>

CREAM CLI commands

  The most relevant commands to interact with CREAM based CEs are:
Line: 120 to 120
  All these commands are described in the following sections.
Changed:
<
<

0.1 Submitting jobs to CREAM based CEs

>
>

Submitting jobs to CREAM based CEs

  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 one or more job description files; each file describes the job characteristics and requirements through the JDL (Job Description Language). A typical example of a JDL job description file is:
Line: 172 to 172
  The command returns the CREAM job identifiers associated with these jobs (e.g. https://cream-ce-01.pd.infn.it:8443/CREAM116j9vgnf) which identify them in clear and unique way all over the Grid system scope.
Changed:
<
<

0.1 Monitoring jobs

>
>

Monitoring jobs

  Passing the CREAM job identifiers returned by the glite-ce-job-submit command to the glite-ce-job-status command, it is possible to monitor the submitted jobs. Several (static and dynamic) information can be shown, depending on the chosen verbosity level. The verbosity level can be 0 (less verbosity), 1 or 2 (most verbosity).
Line: 223 to 223
 > glite-ce-job-status --all -e grid005.pd.infn.it:8443 --from 2005-07-23 10:00:00 --to 2005-07-28 11:00:00 -s DONE-OK:DONE-FAILED
Changed:
<
<

0.1 Retrieving output of jobs

>
>

Retrieving output of jobs

  User can choose to save the output sandbox (OSB) files on a remote server, or save them in the CREAM CE node. In the latter case these files can then be retrieved using the glite-ce-job-output command.
Line: 237 to 237
  This command can be used also to retrieve output produced by multiple jobs, by specifying multiple job identifiers as command's arguments .
Changed:
<
<

0.1 Getting job identifiers

>
>

Getting job identifiers

  If a user is interested to get the identifiers of all her jobs submitted to a specific CREAM CE, she can use the glite-ce-job-list command. For example the following command returns the identifiers of all the jobs submitted to the specified CREAM CE, owned by the user issuing the command:
Line: 245 to 245
 > glite-ce-job-list grid005.pd.infn.it:8443
Changed:
<
<

0.1 Cancelling jobs

>
>

Cancelling jobs

  In some cases it might be needed to cancel jobs which have been previously submitted to CREAM based CEs. This can be achieved via the glite-ce-job-cancel command.
Line: 257 to 257
  cancels the specified job.
Changed:
<
<

0.1 Suspending and resuming jobs

>
>

Suspending and resuming jobs

  A running or idle job can be suspended (i.e. its execution will be stopped), and be resumed (i.e. it will run again) later. This can be achieved with the glite-ce-job-suspend and glite-ce-job-resume commands.
Line: 281 to 281
 Status = [REALLY-RUNNING]
Changed:
<
<

0.1 Purging jobs

>
>

Purging jobs

  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.
Line: 293 to 293
  the specified job can’t be managed anymore (e.g. it is not possible to check its status anymore).
Changed:
<
<

0.1 Renewing proxies

>
>

Renewing proxies

  It is possible that long jobs may outlive the validity of the initial delegated credentials; if so the job will die prematurely. To avoid this it is possible to renew the proxy of jobs submitted to CREAM CEs with the glite-ce-proxy-renew command.
Line: 307 to 307
  It must be stressed that for jobs submitted to CREAM based CEs via the Workload Management System (WMS), proxy renewal is automatically dealt by the middleware.
Changed:
<
<

0.1 Handling job identifiers

>
>

Handling job identifiers

  Handling the job identifiers directly quickly becomes tedious. To avoid this, you can make the glite-ce-job-submit and glite-ce-job-list commands append the job Id(s) to a named file using the --output (-o) option. On the other side, the CREAM client commands which take job identifier(s) as argument accept also the --input (-i) option which allows the job identifier(s) to be read from a file.
Line: 326 to 326
 Status=[REALLY-RUNNING]
Changed:
<
<

0.1 Restricting job submissions

>
>

Restricting job submissions

  In order to prevent that a CREAM CE gets overloaded, the CREAM CE administrator can set a specific policy to disable new job submissions when certain conditions are met.
Line: 362 to 362
  It must be stressed that if job submissions to a specific CREAM CE are disabled, all other operations (job status, job cancellations, etc.) can still be performed.
Changed:
<
<

0.1 Getting information about the CREAM service

>
>

Getting information about the CREAM service

  It is possible to get information about the CREAM service (interface and service version, status, etc) using the glite-ce-service-info command, e.g.:
Line: 395 to 395
 https://grid005.pd.infn.it:8443/ce-monitor/services/CEMonitor
Changed:
<
<

0.1 CREAM CLI configuration files

>
>

CREAM CLI configuration files

  The configuration of the CREAM UI is accomplished via three possible configuration files:
Line: 413 to 413
  It must be noted that one or more (even all) of these three configuration files can be missing.
Changed:
<
<

0.0.1 CREAM CLI configuration file attributes

>
>

CREAM CLI configuration file attributes

  We list here the possible attributes that can be specified in the configuration files:
Line: 465 to 465
 As mentioned above, if the same attribute is defined in more than a configuration file, the definition in the user specific configuration file (if any) has higher priority than the definition in the VO specific configuration file (if any), which has higher priority than the definition in the generic configuration file. If an attribute is not defined anywhere, the default value is considered.
Changed:
<
<

0.1 Example of CREAM CLI configuration file

>
>

Example of CREAM CLI configuration file

  The following represents an example of a CREAM UI configuration file:
Line: 489 to 489
 
Changed:
<
<

1 Man pages for CREAM Command Line Interface

>
>

Man pages for CREAM Command Line Interface

 
Line: 507 to 507
 
Changed:
<
<

1 Use specific functionality of the CREAM CE

>
>

Use specific functionality of the CREAM CE

 
Changed:
<
<

0.1 Submission on multi-core resources

>
>

Submission on multi-core resources

  As explained in the CREAM JDL guide, the following JDL attributes:
Line: 523 to 523
  This section explains how this is actually implemented for LSF and Torque/PBS:
Changed:
<
<

0.0.1 First scenario

>
>

First scenario

  With a JDL such as:
Line: 555 to 555
 with S equal to the value published as GlueHostArchitectureSMPSize.
Changed:
<
<

0.0.1 Second scenario

>
>

Second scenario

 

With a JDL such as:

Line: 583 to 583
 
Changed:
<
<

0.0.1 Third scenario

>
>

Third scenario

  With a JDL such as:
Line: 614 to 614
 with S equal to the value published as GlueHostArchitectureSMPSize.
Changed:
<
<

0.0.1 Forth scenario

>
>

Forth scenario

  With a JDL such as:
Line: 649 to 649
 
Changed:
<
<

0.0.1 Fifth scenario

>
>

Fifth scenario

  With a JDL such as:
Line: 686 to 686
 
Changed:
<
<

0.0.1 Sixth scenario

>
>

Sixth scenario

  With a JDL such as:
Line: 711 to 711
 
Changed:
<
<

0.1 Forward of requirements to the batch system

>
>

Forward of requirements to the batch system

  The CREAM CE allows to forward, via tha BLAH component, requirements to the batch system.
Line: 846 to 846
 
Changed:
<
<

1 CREAM job states

>
>

CREAM job states

  Here below is provided a brief description of the meaning of each possible state a CREAM job can enter:
Line: 875 to 875
  cream_job_states.jpg
Changed:
<
<

1 ES Command Line Interface Guide (WORK IN PROGRES...)

1.1 Before starting: get your user proxy

>
>

ES Command Line Interface Guide (WORK IN PROGRES...)

Before starting: get your user proxy

 See above: get your user proxy
Changed:
<
<

0.1 ES CLI Commands:

>
>

ES CLI Commands:

 
  • glite-es-activity-create --endpoint <hostname>[:tcpport] [OPTIONS] <ADL_FILE>
  • glite-es-activity-status --endpoint <hostname>[:tcpport] [OPTIONS] <Activity_Identifier_1> ... <Activity_Identifier_N>
Line: 912 to 912
 

http://devel15.cnaf.infn.it/
Added:
>
>
devel15.cnaf.infn.it/ devel15.cnaf.infn.it/somepath
 http://devel15.cnaf.infn.it:8443/anything https://devel15.cnaf.infn.it myprotocol://lxgrid05.pd.infn.it
Line: 944 to 946
  glite-es-notify-service sends to the server, specified as endpoint, a notification message (see below for the kind of messages available)
Changed:
<
<

0.1 Creating simple activities on ES based CEs (no Input/Output sandboxes)

>
>

Creating simple activities on ES based CEs (no Input/Output sandboxes)

 
Changed:
<
<
The command glite-es-activity-create creates an activity on an ES based CE; it needs the specification of and endpoint where the creation request must be sent, and an XML file containing the activity description (described in ADL language: https://twiki.cern.ch/twiki/bin/view/EMI/EmiExecutionService). The XML must not contain any xml namespace. A simple example (sleeping job) for content of ADL_FILE is:
>
>
The command glite-es-activity-create creates an activity on an ES based CE; it needs the specification of and endpoint where the creation request must be sent, and an XML file containing the activity description (described in ADL language: https://twiki.cern.ch/twiki/bin/view/EMI/EmiExecutionService). The XML must not contain any xml namespace. A simple example (sleeping job) is:
 

$ cat ~/JDLs/simple_activity.adl
Line: 995 to 998
 

Please note some useful information returned by the server in addition to the activity's identifier (CR_ES146448265):

Added:
>
>
 * Status = PREPROCESSING, saying an obvious thing: just after activity creation, its status is still in a preliminary state waiting to be run somewhere
Added:
>
>
 * Timestamp      = Tue Mar 20 10:16:23 2012, information about timestamp of actual activity creation on the server
Changed:
<
<
* STAGEIN/STAGEOUT that we can ignore right now; we will see them later
>
>
* STAGEIN/STAGEOUT that we can ignore right now; we will discuss them later
 
Changed:
<
<

0.0.1 Monitoring activities on ES based CEs

>
>

Monitoring activities on ES based CEs

  Obtaining the status of one or more activities is as simple as issuing this command:
 
Line: 1015 to 1021
 
Changed:
<
<
After a while the user's activity will be finised:
>
>
After a while the user's activity will be finished:
 
 

$ glite-es-activity-status  -e cream-10.pd.infn.it CR_ES146448265
Line: 1028 to 1034
 
Changed:
<
<

0.1 Creating activities on ES based CEs, that need to move Input/Output sandboxes

>
>
Of course the user can specify more than one activity identifier as argument of status command:
 
Changed:
<
<
The previous example was about a simple activity that doesn't involve sandboxes to move around; if the user needs to send one or more files to the CE, or needs that the CE sends files after job execution, then a more complex activity must be written and sent to the CE; before to create the activity a delegation must be created on the CE (or "a proxy must be delegated on the CE"), because moving the sandbox files could imply to contact remote authenticated services, like GridFTP servers. To delegate his/her own proxy on the CE, the user has to issue this command:
>
>
$ glite-es-activity-status -e cream-10.pd.infn.it CR_ES918217695 CR_ES499424509 *************************************** JobID = CR_ES499424509 Status = TERMINAL Attributes = {} Timestamp = Wed Mar 21 09:45:57 2012 Description = reason=0 *************************************** JobID = CR_ES918217695 Status = TERMINAL Attributes = {} Timestamp = Wed Mar 21 09:45:48 2012 Description = reason=0

Creating activities on ES based CEs, that need to move Input/Output sandboxes

Automatically stage-in/stage-out performed by the CE

The previous example was about a simple activity that doesn't involve sandboxes to move around; if the user needs to send one or more files to the CE, or needs that the CE sends files after activity termination, then a more complex activity must be written and sent to the CE; before to create the activity a delegation must be created on the CE (or "a proxy must be delegated on the CE"), because moving the sandbox files could imply to contact remote authenticated services, like GridFTP servers. To delegate his/her own proxy on the CE, the user has to issue this command:

 

$ glite-es-delegate-proxy cream-10.pd.infn.it
Line: 1038 to 1064
 
Changed:
<
<
The returned delegation identifier 04669318871724504 (that is an handle to the real delegated proxy residing on the CE cream-10.pd.infn.it, whose lifetime is equal to the user's proxy lifetime) must be inserted in the proper ADL's section, like in this example:
>
>
The returned delegation identifier 04669318871724504 (that is an handle to the real delegated proxy residing on the CE cream-10.pd.infn.it, whose lifetime is equal to the user's proxy lifetime) must be inserted in the proper ADL's section, like in this example:
 
$ cat ~/JDLs/activity_files.adl 
Line: 1119 to 1145
 
Added:
>
>
In the last example, the activity represent a job to execute, and it is not a system executable (like the /bin/sleep of the previous example); the executable is built up by the user, myjob.sh, and must be staged out from a storage server (cream-23.pd.infn.it in this example; see again the <Source> node in the ADL above) running a GridFTP daemon, into the activity's directory in the CE. We do not enter into the job's details: simply note that the user's executable produces a standard output, and a standard error that will be redirected to dedicated files (the JobOutput.txt and JobError.txt specified in the ADL above). The standard output will contain the print of a particular user-defined environment variable (MY_ENV, see the ADL above) and an echo message; the standard error will contain an error message triggered by operations that the user cannot perform on the destination worker node.

In the ADL it is written that the two files JobOutput.txt and JobError.txt must be sent to the storage server (the same GridFTP server seen before for the executable stage-out) cream-23.pd.infn.it; of course it could be a different storage server. The user can retrieve these output files by mean of hist/her preferred GridFTP client. For example:


$ globus-url-copy gsiftp://cream-23.pd.infn.it/tmp/JobOutput.txt JobOutput.txt
$ globus-url-copy gsiftp://cream-23.pd.infn.it/tmp/JobError.txt JobError.txt
$ ls -l Job*
-rw------- 1 dorigoa dorigoa 120 Mar 21 10:31 JobError.txt
-rw------- 1 dorigoa dorigoa  73 Mar 21 10:31 JobOutput.txt

Please note that the destination CE cream-10.pd.infn.it has sent the two files JobOutput.txt and JobError.txt to the storage server cream-23.pd.infn.it using the proxy that the user delegated before (identified by the string 04669318871724504, that has been put in the ADL file) for authentication. The delegated proxy must be valid when the stage-in occurs. Then it is up to the user to delegate a proxy into the CE, that has a lifetime long enough for the entire time of the job's life and files stage-in.

Stage-in performed by the user

 

-- MassimoSgaravatto - 2011-04-07

Line: 1123 to 1165
  -- MassimoSgaravatto - 2011-04-07
Deleted:
<
<
 -- MassimoSgaravatto - 2012-03-14
Changed:
<
<
-- AlviseDorigo - 2012-03-20
>
>
-- AlviseDorigo - 2012-03-21
 
META FILEATTACHMENT attachment="cream_job_states.jpg" attr="" comment="" date="1331716396" name="cream_job_states.jpg" path="cream_job_states.jpg" size="18586" user="AlviseDorigo" version="1"
 
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