[jsdl-wg] Questions about JSDL specification

[Michel Drescher]

Hi Alain,

please find my answers inlined below.

Alain Roy wrote:
> Hello,
> 
> I have been reading the JSDL specification, and I have a few questions 
> about it.
> 
> 1) I want to make sure that I understand "support" and "satisfy" as 
> defined on page 7. If a system can parse a JSDL document, then it 
> supports it, and if it can do everything requested by the JSDL document, 
> then it satisfied it. Is that correct?

Yes.

> 2) Just to make sure I understand support, when it says "The JSDL core 
> element set contains the semantics for elements that are defined by JSDL 
> 1.0. All elements MUST be supported by JSDL 1.0 compliant consuming 
> systems.", that simply means that they need to be parsed, not that the 
> need to be accepted, correct?

Yes, in the sense that "accepted" here means that the semantics attached 
to that XML element will be actually carried out.

"Support" means that the consuming entity can parse that XML element, 
and inherently knows its semantics.
"Satisfy" means that the consuming entity is able to (and will) execute 
the semantics attached to a particular JSDL XML element.

> 3) ApplicationName identifies the executable. I don't understand where 
> the executable comes from. Do we expect that the underlying system can 
> figure out which program to run from the name and version, and that it 
> is pre-staged? Can applications bring their executable with them by 
> staging it? Am I supposed to use the POSIXApplication element? I'm 
> confused how this fits together.

Consider jsdl:ApplicationName and jsdl:ApplicationVersion together. The 
use case is that, for popular applications such as BLAST, the user just 
need to give a "well known" application name, i.e. a name that the 
consuming system reckognises, and an appropriate version number if this 
is of any relevance. The consuming system then can figure out the path 
to the concrete BLAST executable and use it accordingly.
Considering more than one consuming entities, this mechanism allows the 
user to submit her JSDL job to another system without modifications, 
provided that both understand the same "well known" application name.
Another benefit is that this separates concerns: THe user only need to 
be concerned about which application he wants to run, and the execution 
system needs to be concerned whether it can provide this application, 
and in the correct version, and what the path to that application 
actually is.

If you really need to run your own executable (which is, honestly, quite 
common), then you use the jsdl:POSIXApplication extension, which allows 
you to specify the direct path to that executable along with necessary 
additional information. Then you do not have to specify 
jsdl:ApplicationName and jsdl:ApplicationVersion elemments, or the 
connsuming entity would simply ignore them in the presence of a 
jsdl:POSIXApplication element.


> 3) When I specify the operating system: how do I specify linux version? 
> Kernel version? Distro + version? Is it dependent on the underlying system?

Specifying a particular distribution is a very hairy topic. As you know, 
Linux distributions are more or less all the same in the sense that they 
provide a kernel (Linux) and "all the stuff around". I think Linux 
distributions, or rather their default installation, can be seen as 
profiles on the same space of software available for Linux.

In that sense I thing the best effort is to try to specify the kernel 
version. But this is not satisfactory enough, I know. :-/

> 3) IndividualCPUCount allows me to specify a range in terms of double: 
> what does this mean? For example, if I specify that I want 3.14 CPUs, 
> it's a legal specification, but I don't know what it means. Ditto for 
> IndividualPhysicalMemory and IndividualVirtualMemory and 
> IndividualDiskSpace.

Without checking the spec, I guess this is an artefact how ranges are 
given in JSDL - to be able to use one Range type for all sorts of 
resources, we decide to use xsd:double as this includes integers.

So you may want to specify 3.14 for jsdl:IndividualCPUCount, but the 
consuming system then may
- throw the JSDL doc back at you nagging about silly values, or
- accept the document and use 3.0 instead, or
- do something else, e.g. cause a kernel panic in the underlying OS. ;-)

> 3) I don't undersatnd IndividualNetworkBandwidth: bandwidth to where? 
> Does this refer just to the local NIC? What if there are multiple NICs?
> 
> 4) I'm confused how IndividualDiskSpace interacts with the filesystem 
> element. The FileSystem element specifies how much disk space is needed 
> on a particular file system: the IndividualDiskSpace says something 
> about disk space, but not about where the disk space is located. Which 
> disk space is it? What does it mean if I specify a FileSystem and 
> IndividualDiskSpace?
> 
> 5) I don't understand the difference between IndividualCPUCount and 
> TotalCPUCount. Can I think of it as the number of CPUs on a single node, 
> and the total number needed across all nodes? Or does it mean something 
> different?

Consider the jsdl:Individual* and jsdl:Total* elements together with the 
jsdl:ResourceCount element.
They are used to express a tiled topology. I hope someboody else can 
step in here and give a more detailed description.

> 6) When I stage files, the destination might be a filesystem on NFS. If 
> I'm running many jobs at the same time, the files might clobber each 
> other unless I give the files unique names: is the user responsible for 
> doing so, or is there some way to specify a unique identifier in the 
> file name? For example, in Condor I can say something like 
> File.$(Process) to get a unique filename based on the job id.

No. In JSDL, the user is responsible for unique file names. On the other 
hand, you can specify whether the system shall overwrite any existing 
file with that name or not.

Cheers,
Michel

-- 
Michel <dot> Drescher <at> uk <dot> fujitsu <dot> com
Fujitsu Laboratories of Europe
+44 20 8606 4834