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