[jsdl-wg] Port and xRSL

A Stephen McGough asm100 at doc.ic.ac.uk
Mon Nov 29 10:30:06 CST 2004


I'd like to add one final comment to those of Donal,

 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.

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.

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
------------------------------------------------------------------------






More information about the jsdl-wg mailing list