Hi, I searched the archive of the list for Port and for xRSL, and found nothing, though I want to throw in my two cents: 1. Port In the Network section of a WSDL file I didn't found any way to request specific ports to be opened for incoming/outgoing/tcp/udp connections and if net is NAT'ed etc. I have quite often submitted jobs with need for specific ports and it would hence be nice to be able to specify this in stead of having the job fail. 2. xRSL As JSDL is based on Condor, RSL and others I just wanted to point to NorduGrids xRSL. It is (eXtended RSL) to it is mostly covered by RSL, however, there is some additions that I think could be usefull for JSDL: * runtimeEnvironment: Specifies specific software requirements on the cluster (like Gaussian, ATLAS and others.) It could though be added as an extention to JSDL. * nodeAccess: inbound|outbound essentially a light version of the Port sepecified above. Cheers, Michael Michael Grønager, PhD Research and Developement, VR-C UNI-C DTU Build. 304 DK2800 Lyngby DENMARK Phone: +45 35878889 Direct: +45 24248207 Fax: +45 35878990 Email: mpg@uni-c.dk
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.
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 ------------------------------------------------------------------------
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 ------------------------------------------------------------------------
participants (3)
-
A Stephen McGough -
Donal K. Fellows -
Michael Grønager