Stephen,
From what I see the JSDL group are defining the _core_ set of features that a JSDL language should contain. We should encourage groups to write extension sets to the core. These may in time become part of a JSDL standardised extension set.
Agree. However, as mentioned in my last post, I see little value of a WebService jobtype if no ports can be requested opened...
So Michael, I'd encourage you to develop an extension set that deals with those aspects that are not in the core JSDL. We can then discuss these through the JSDL with three possible outcomes (for each element suggested): 1) Add this to the core JSDL as we discover it is essential for all JSDL consumers, 2) Add it to a subset of a supported extension to JSDL, or 3) Encourage you to develop it as an external to the core JSDL set of extensions.
Thanks - I will write it into an extension to start with. btw do you have a pointer to other extensions as a template?
On this note it may be useful to allow a document to be taged with extension sets and versions as well as JSDL versions. What do people think? Can we bring this up at the next telelcon?
steve..
Donal K. Fellows wrote:
Michael Grønager wrote:
I searched the archive of the list for Port and for xRSL, and found nothing, though I want to throw in my two cents:
Looking at this, I feel that these things will either be fine for extensions or are already covered. Generally speaking, I'm going to try to argue here why changes to JSDL to achieve what you want are not needed; this is not because you're putting forward bad suggestions though! I just want to keep the number of changes to the doc small so that we have a chance to get a first revision of a standard done quickly, leaving many good ideas for future work (we already have a list of possible resources for future work.)
1. Port
This would be fine as an extension in the Resources section, though the semantics would have to be that the job requires the given ports to be open (in general, you'd want to be able to also specify where it is open with respect to.)
(FWIW, in my jobs the requirement to have a particular port or port-range open is a bug, but then I structure my things differently and I'm also working in quite a different environment to you apparently. Just because I don't need it doesn't mean that it isn't valuable. But it does fit nicely as an extension.)
2. xRSL * runtimeEnvironment: Specifies specific software requirements on the cluster (like Gaussian, ATLAS and others.) It could though be added as an extention to JSDL.
These things are either covered by the existing ApplicationName element (Gaussian is one of our use-cases) or by other extensions within either the Application or the Resources element (depending on the exact nature of the kind of requirement). I'd like to emphasize that the Application element as it stands is (when you take advantage of it fully) a lot richer than many current job running systems support.
* nodeAccess: inbound|outbound essentially a light version of the Port sepecified above.
Then it's either covered by what I said above :^) or you'll need to provide a bit more explanation (e.g. a URL where I can look up what those terms really mean).
I hope this message doesn't come across as combative; it's not meant to. I'm just trying as hard as possible to describe things in terms of what is already there to minimize the amount of work we need to do. :^)
Donal.
-- ------------------------------------------------------------------------ Dr A. Stephen McGough ------------------------------------------------------------------------ Research Associate, Imperial College London, Department of Computing, 180 Queen's Gate, London SW7 2BZ, UK tel: +44 (0)207-594-8310 fax: +44 (0)207-581-8024 ------------------------------------------------------------------------ Assistant Warden, West Wing, Beit Hall, Imperial College, Prince Consort Road, London, SW7 2BB tel: +44 (0)207-594-9910 ------------------------------------------------------------------------