| |
Comment: |
[From Mark]
We actually have taken some of the extensions that we did for JSDL out in favor of more standard ways of accomplishing the same thing. For example,
we use to have an element in the resources section that indicated that the user was going to mount the grid namespace using OGRSH. However, when we
deprecated OGRSH in favor of a FUSE file system driver, we went ahead and did the "right" thing and move the equivalent element into the Filesystem
elements included in JSDL.
Currently, we use the following JSDL extensions.
* First of all, we fully support the HPC Profile as well as the HPC File Staging Extensions
* We support the SPMD Application element that the JSDL group released
* We still support the POSOX Application element as well.
Inside of the Resources section of the JSDL element we support the following extensions
* We added a WallclockTime element which we use for scheduling jobs on Batch System backends. The elements that came with JSDL seemed to not be
sufficient. The one in Resources was for CPU time, not wallclock time. There was a wallclock time element in the POSIX Application, but since it
isn't in HPC profile, we didn't want to have to support the POSIX one and an extension to HPC when we could just extends Resources.
* We added a new element type to Resources called MatchingParameters which are a [0, infinite) collection of arbitrary name-value pairs. These are
matched against equivalent name-value pairs that our BES containers advertise for the purposes of scheduling as well. Examples of such name-value
pairs include:
- supports-matlab=true
- R-version=12.4 (I'm lying about the version -- I don't know what versions R has)
* We are in the process of extending the OperatingSystemType element because we now have quite a few Windows Vista machines
* Our grid queues can take either JSDL documents, or what we called batch-jsdl documents. A batch JSDL document is a collection of 0 or more JSDL
documents wrapped inside a single pair of <multi> tags. This allows users to submit large batches of JSDL documents in a single call quite easily.
You asked about PortTypes that we have for JSDL -- I'm not entirely sure what you mean here. JSDL is a specification language and so port types that
interact with the JSDL seems irrelevant. However, if you want to know what port types we have that can accept or return JSDL
* BES Factory
* BES Activity
* Genesis II Queue
* ByteIO
* RNS
|
