[graap-wg] JSDL cheat sheet

Karl Czajkowski karlcz at univa.com
Mon Mar 28 19:45:33 CST 2005


In the absence of a revised JSDL document w/ all the work items
completed that were generated at GGF-13, here are some notes I took
for myself on the basic structure and scope...

Please note that there are two ways to look at the resource
constraints (this is one of the most metaphysical aspects of job
scheduling):

  1) implied performance requirements via physical resource selection

  2) qualitative features of the job configuration

I think the JSDL view is more towards (2), meaning that the resource
constraints describe basic "shape" of a job. They need to be
complemented by more performance-oriented constraints including
wall-clock lifecycle and/or performance of hardware (CPUs,
interconnects, disks, hierarchical RAM, etc.).

I think JSDL is extensible enough to insert performance constraints
into its structure, so I do not know if it is better to do this or use
an external annotation format for composing JSDL, performance metrics,
and WS-Agreement.


karl


JSDL cheat sheet
----------------

There is an explicit understanding that the base JSDL doc element
allows expression of homogeneous parallel jobs, and sequential
jobs. To express heterogeneous parallel jobs, or heterogeneous
"alternates" (a Unicore idea?), will require an enclosing context that
presents a set of JSDL job documents w/ some way to interpret them for
this purpose.  In other words, a multi-job like syntax could represent
either "do all these simultaneously" or "choose one of these that fits
the resource pool".

It will take some time for a new draft to settle out w/ all the
revision decisions enacted. We pushed a lot of stuff out of scope and
tried to fix a lot of warts. Here is a rough sense of the structure,
without trying to write a schema right now:

  JobDefinition
     JobDescription
        JobIdentification ?
           JobName ?
           Description ?
           JobAnnotation *
           JobProject *
           xsd:any##other
        User ?
           ExecutionUserID ?
           ExecutionGroupID ?
           UserGroup *
           xsd:any##other *
        Application ?
           ApplicationName ?
           ApplicationVersion ?
           ExecutableApplication ?
              Executable
              Argument (xsd:string) *
              Environment (xsd:string) *
                 attr: name=xsd:string
              Input ?                                                                                                                          
              Output ?                                                                                                                         
              Error ?
              WorkingDirectory ?
              PosixStackLimit ?
              PosixProcessLimit ?
              ...
              PosixMaxFilesizeLimit ?
              xsd:any##other *
           xsd:any##other?
        Resource ?
           HostName *
           ResourceCount ?
           CPUArchitecture ?
           TotalCPUCount ?
           TotalRAM ?
           ...
           PerResourceCPUCount ?
           PerResourceRAM ?
           ...
        DataStaging *
           FileName
           FileSystemID ?
           CreationMode
           DeleteOnTermination ?
           Source ?
              URL
           Target ?
              URL
           xsd:any##other ?
        xsd:any##other *
     xsd:any##other *

The Input and Output elements are actually complex structures to do
the expected things such as associating source/destination URLs with
local filenames or filespaces.

The types of many obvious things are xsd:string.  The types of the
"resource constraint" numerical limits will be a ValueRangeType that
basically is something like this:

   sequence
      <Exact>xsd:integer</Exact> *
      <LessThan>xsd:integer</Exact> *
      <GreaterThan>xsd:integer</GreaterThan> *
      <Between>
         <Lower>xsd:integer</Lower>
         <Upper>xsd:integer</Upper>
      </Between> *

to allow the structured expressionf of their previous "string range
value language" which allowed things like:

   a, b, c, d-e, f-, -g

to give a mixed list of values, intervals, and semi-spaces.


-- 
Karl Czajkowski
karlcz at univa.com





More information about the graap-wg mailing list