JSDL vs NorduGrid xRSL: a comparison (fwd)
Forwarding bounced mail on behalf of Oxana Smirnova, NorduGrid. Ali -- ---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali@epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 ------------------------------------------------------------- ---------- Forwarded message ---------- Date: Mon, 09 May 2005 14:52:43 +0200 From: Oxana Smirnova <oxana.smirnova@hep.lu.se> To: jsdl-wg@gridforum.org, egee-project-crm <egee-project-crm@cern.ch>, NorduGrid Discussion <nordugrid-discuss@nordugrid.org> Subject: JSDL vs NorduGrid xRSL: a comparison Dear all, as agreed by the Compute Resource Management Interfaces (CRM) initiative, JSDL has been evaluated by the participating Grid system experts against job description languages presently in use. NorduGrid's ARC uses extended Globus RSL (xRSL), which can be quite easily mapped to the POSIX Application of JSDL. However, there are several elements that are missing from JSDL but have been proven to be essential for proper Grid job description and execution - at least from the NorduGrid perspective. JSDL appears to be a proper framework for a more advanced Grid job description, provided it can be extended to: a) accomodate more elements (most notably, Run-time Environment for an application) b) enable multiple job definitions in a single "script"/file c) allow for alternative parameter requests (e.g., alternative OS, environment, host etc) A detailed comparison and related notes can be downloaded at http://www.nordugrid.org/documents/jsdl-vs-xrsl-revised2.sxw Hopefully, this can be taken as an input for further JSDL development. NorduGrid so far did not participate in JSDL-WG activities, but can contribute in future, if the WG members find it useful. Best regards, Oxana Smirnova, for the NorduGrid collaboration
Oxana Smirnova wrote: [...]
a) accomodate more elements (most notably, Run-time Environment for an application) b) enable multiple job definitions in a single "script"/file c) allow for alternative parameter requests (e.g., alternative OS, environment, host etc) [...] Hopefully, this can be taken as an input for further JSDL development. NorduGrid so far did not participate in JSDL-WG activities, but can contribute in future, if the WG members find it useful.
Thank you for your input. The following responses are merely my opinion on your three points, but I suspect that many other WG members will agree. a) This should be possible through either the existing subelements of the POSIXApplication element, or through extension. However I'd love to see more input from you on this as part of the development of the next version of the spec. b) This should be done by wrapping the JSDL singletons inside some larger XML dialect that describes the relationship of the basic jobs to each other. Although we want to support workflows, we've always pushed the workflow bit of it out of scope so we can get agreement on the rest of everything. :^) c) I think we're punting this one out to WS-Agreement (over a space of JSDL terms). It gets really complicated otherwise as you start to try to describe spaces of coupled terms... In summary, "why isn't it possible now", "out of scope", and "out of scope". But that's just a bit short and I think you'll prefer the longer outline above. ;^) Donal.
Hello Donal, many thanks for replying, hope you (or other group members) also had time to look through the document. I am new to JSDL business, but have quite some experience with "real" job description languages used for great variety of applications in EDG/LCG/gLite (JDL) and NorduGrid/ARC (xRSL), thus I have some questions that perhaps are just FAQ of this group, see below.
a) This should be possible through either the existing subelements of the POSIXApplication element, or through extension. However I'd love to see more input from you on this as part of the development of the next version of the spec.
There are several elements that can be easily added; runtimeenvironment is just one of them. What is this group's criteria for an element to be added to the specs? What kind of arguments should I present to support each case? Would it be sufficient to tell that few hundred users find it convenient, and so do Grid m/w developers and site owners?
b) This should be done by wrapping the JSDL singletons inside some larger XML dialect that describes the relationship of the basic jobs to each other. Although we want to support workflows, we've always pushed the workflow bit of it out of scope so we can get agreement on the rest of everything. :^)
I don't think that describing several jobs in one script has anything to do with workflow. It's up to the workload management system to interpret it, but for the user's convenience it would be nice to include into JSDL a possibility to specify several jobs. No need for a "larger XML dialect", just one more super-element. Here's a use case: I want to submit 10000 jobs that differ only in one input parameter. I have a tool that generates JSDL; and I'd hate to fill my disk with 10000 small files. You are not going to create a dedicated workgroup to produce a two-line spec that describes JSDL concatenation, are you?
c) I think we're punting this one out to WS-Agreement (over a space of JSDL terms). It gets really complicated otherwise as you start to try to describe spaces of coupled terms...
Eh, nobody promised it's going to be easy :-) I understand that XML is just a markup language, not quite suited for task definition, because task description normally includes conditions "if then else", relations "and", "or", and negations "not". For example, "buy X amount of apples if they are red, else buy Y amount of pears and Z amount of bananas". This is a single task, these are not separate jobs. It does not describe workflow, because it does not specify in which shop these apples or pears should be purchased (doesn't even say it should be the same one), or when, and not even the price. JSDL presently can't describe such a job. I don't even see how two separate job descriptions can be merged by another *XML* dialect into one - XML is not really made for it. In real life, I've had plenty of jobs like "if a site has outbound connectivity, stage in this, else stage in something different". Globus' RSL allows this, and I'm sure it's a part of job description, not workflow. It is an instruction for the execution site, not for the workload manager/broker.
In summary, "why isn't it possible now", "out of scope", and "out of scope". But that's just a bit short and I think you'll prefer the longer outline above. ;^)
I'd like to learn what is the scope, I guess - and where to submit things that are out of it :-) Oxana
Dear Oxana, Here is a quick reply to your request. Rather than address the individual issues you have raised I'll give a brief description of why the scope of the JSDL group is as it is. The JSDL group started with a broad vision of providing a full XML language for job submission into the Grid (as an aside I came to the group with JDML and XML version of JDL from EDG). This however proved to be far too much to get agreement on. You talk of "this isn't workflow its just ...", many people came to the group saying similar things. This became a big problem for JSDL as people came along with such items each of which didn't make a workflow language but the sum of them did. This put the group into stagnation as arguments about workflow overwhelmed the group. Since this we have taken anything that could lead to this and put it out of scope. That is not to state that it will always be out of scope - but rather we class it as out of scope until JSDL 1.0 is complete. Once we have achieved this goal we shall re-visit many of these areas and see how they can be adopted into JSDL - or potentially propose the formation of new groups to define how to achieve these "features". We are aware of many users and system developers that require many of the features that you discuss. However, in order to get any form of spec out we have tightened the spec down to the submission of a single job with a hard set of requirements. To take a specific example of the parameter sweep application case you describe - I am aware of groups using JSDL who desire these features and they are looking into extensions to JSDL which will allow this without the need to generate thousands of JSDL documents. Though as stated already this is well outside the scope of JSDL 1.0. To help you to understand what we have defined to be in and out of scope I'll refer you to the JSDL document section 3 (the current version can be located at https://forge.gridforum.org/projects/jsdl-wg/document/draft-ggf-jsdl-spec/en...). As to where to submit items which are out of scope. We are currently working on outputting v. 1.0 of JSDL and you can propose items that we should look into post 1.0. However, if you feel that the item is well outside of our defined scope you may decide it is best to form your own group in GGF to work in that area. Many people in the JSDL group may wish to join in on such effort if appropriate to their core desires. Hope this is of some help, steve.. Oxana Smirnova wrote:
Hello Donal,
many thanks for replying, hope you (or other group members) also had time to look through the document. I am new to JSDL business, but have quite some experience with "real" job description languages used for great variety of applications in EDG/LCG/gLite (JDL) and NorduGrid/ARC (xRSL), thus I have some questions that perhaps are just FAQ of this group, see below.
a) This should be possible through either the existing subelements of the POSIXApplication element, or through extension. However I'd love to see more input from you on this as part of the development of the next version of the spec.
There are several elements that can be easily added; runtimeenvironment is just one of them. What is this group's criteria for an element to be added to the specs? What kind of arguments should I present to support each case? Would it be sufficient to tell that few hundred users find it convenient, and so do Grid m/w developers and site owners?
b) This should be done by wrapping the JSDL singletons inside some larger XML dialect that describes the relationship of the basic jobs to each other. Although we want to support workflows, we've always pushed the workflow bit of it out of scope so we can get agreement on the rest of everything. :^)
I don't think that describing several jobs in one script has anything to do with workflow. It's up to the workload management system to interpret it, but for the user's convenience it would be nice to include into JSDL a possibility to specify several jobs. No need for a "larger XML dialect", just one more super-element. Here's a use case: I want to submit 10000 jobs that differ only in one input parameter. I have a tool that generates JSDL; and I'd hate to fill my disk with 10000 small files. You are not going to create a dedicated workgroup to produce a two-line spec that describes JSDL concatenation, are you?
c) I think we're punting this one out to WS-Agreement (over a space of JSDL terms). It gets really complicated otherwise as you start to try to describe spaces of coupled terms...
Eh, nobody promised it's going to be easy :-) I understand that XML is just a markup language, not quite suited for task definition, because task description normally includes conditions "if then else", relations "and", "or", and negations "not". For example, "buy X amount of apples if they are red, else buy Y amount of pears and Z amount of bananas". This is a single task, these are not separate jobs. It does not describe workflow, because it does not specify in which shop these apples or pears should be purchased (doesn't even say it should be the same one), or when, and not even the price. JSDL presently can't describe such a job. I don't even see how two separate job descriptions can be merged by another *XML* dialect into one - XML is not really made for it. In real life, I've had plenty of jobs like "if a site has outbound connectivity, stage in this, else stage in something different". Globus' RSL allows this, and I'm sure it's a part of job description, not workflow. It is an instruction for the execution site, not for the workload manager/broker.
In summary, "why isn't it possible now", "out of scope", and "out of scope". But that's just a bit short and I think you'll prefer the longer outline above. ;^)
I'd like to learn what is the scope, I guess - and where to submit things that are out of it :-)
Oxana
-- -- ------------------------------------------------------------------------ Dr A. Stephen McGough http://www.doc.ic.ac.uk/~asm ------------------------------------------------------------------------ Technical Coordinator, London e-Science Centre, Imperial College London, Department of Computing, 180 Queen's Gate, London SW7 2BZ, UK tel: +44 (0)207-594-8409 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 ------------------------------------------------------------------------
Dear Oxana, many thanks for your feedback and comments. It is clear that you can make a valuable contribution to the work of the group. I am very sorry that you have joined us so very late in the day :( In order to understand the choices that we have made, you need to know the history of the group and our work over the years. Workflow, scheduling, and security are out of scope of JSDL. Of course there are a number of levels of granularity to each of these areas and it is very much up to the definitions that the group has assigned to these issues. e.g. a parametric job is workflow in our view of the job submission world. ...I would not expect that you would have 1000s of job documents for a parameter sweep, I would expect, however, that your submission/job management system can handle the fact that the same job description defines a parametric job where the value of a single argument for the job executable is changed accordingly. It is a matter of opinion as to whether adding this metadata to the JSDL is any better than adding it to a workflow layer or not. As to your question of how one might add new elements/concepts to the JSDL spec, I'm afraid that it takes more than just the popularity of adding that element amongst users. In order for you to suggest normative change it has to fit in with JSDL's purpose and scoping. ...I'm afraid that it is impossible for us to consider adding any substantially new elements for v1.0 of the spec and schema at this stage. We are on the way to putting this version out the door very soon and new additions will have to be lined up for discussion for a post-v1.0 spec and schema. We expect that you will be keen to participate in the public comment period for JSDL v1.0 this summer. You are right that some notion of logic and preference is needed in job scheduling, however, we have put this out of scope for v1.0 so that we can allow the description of simple, absolute job requirements. Grid work is very very complicated and as you say no one said it was going to be easy. However, the JSDL philosophy has always been "keep it simple", "learn to walk before you run" and be pragmatic. We want to try and satisfy simple needs of the majority of users first then look to satisfying the more complex scenarios. I do hope that you understand our points and that you'll keep tuned in to help us improve the JSDL spec and schema. The scope of JSDL will be made clearer in the spec very soon. If it still does not answer your questions, we're not doing our job and should try harder. Please also note that the team is working on releasing a primer following release of v1.0 of the spec and schema, and this is where we will, hopefully, provide practical examples of how to use JSDL. Many thanks for your comments and please continue to help us improve the JSDL. Cheers and take care, Ali On Wed, 11 May 2005, Oxana Smirnova wrote:
Hello Donal,
many thanks for replying, hope you (or other group members) also had time to look through the document. I am new to JSDL business, but have quite some experience with "real" job description languages used for great variety of applications in EDG/LCG/gLite (JDL) and NorduGrid/ARC (xRSL), thus I have some questions that perhaps are just FAQ of this group, see below.
a) This should be possible through either the existing subelements of the POSIXApplication element, or through extension. However I'd love to see more input from you on this as part of the development of the next version of the spec.
There are several elements that can be easily added; runtimeenvironment is just one of them. What is this group's criteria for an element to be added to the specs? What kind of arguments should I present to support each case? Would it be sufficient to tell that few hundred users find it convenient, and so do Grid m/w developers and site owners?
b) This should be done by wrapping the JSDL singletons inside some larger XML dialect that describes the relationship of the basic jobs to each other. Although we want to support workflows, we've always pushed the workflow bit of it out of scope so we can get agreement on the rest of everything. :^)
I don't think that describing several jobs in one script has anything to do with workflow. It's up to the workload management system to interpret it, but for the user's convenience it would be nice to include into JSDL a possibility to specify several jobs. No need for a "larger XML dialect", just one more super-element. Here's a use case: I want to submit 10000 jobs that differ only in one input parameter. I have a tool that generates JSDL; and I'd hate to fill my disk with 10000 small files. You are not going to create a dedicated workgroup to produce a two-line spec that describes JSDL concatenation, are you?
c) I think we're punting this one out to WS-Agreement (over a space of JSDL terms). It gets really complicated otherwise as you start to try to describe spaces of coupled terms...
Eh, nobody promised it's going to be easy :-) I understand that XML is just a markup language, not quite suited for task definition, because task description normally includes conditions "if then else", relations "and", "or", and negations "not". For example, "buy X amount of apples if they are red, else buy Y amount of pears and Z amount of bananas". This is a single task, these are not separate jobs. It does not describe workflow, because it does not specify in which shop these apples or pears should be purchased (doesn't even say it should be the same one), or when, and not even the price. JSDL presently can't describe such a job. I don't even see how two separate job descriptions can be merged by another *XML* dialect into one - XML is not really made for it. In real life, I've had plenty of jobs like "if a site has outbound connectivity, stage in this, else stage in something different". Globus' RSL allows this, and I'm sure it's a part of job description, not workflow. It is an instruction for the execution site, not for the workload manager/broker.
In summary, "why isn't it possible now", "out of scope", and "out of scope". But that's just a bit short and I think you'll prefer the longer outline above. ;^)
I'd like to learn what is the scope, I guess - and where to submit things that are out of it :-)
Oxana
-- ---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali@epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------
Oxana Smirnova wrote:
a) This should be possible through either the existing subelements of the POSIXApplication element, or through extension. However I'd love to see more input from you on this as part of the development of the next version of the spec.
There are several elements that can be easily added; runtimeenvironment is just one of them. What is this group's criteria for an element to be added to the specs? What kind of arguments should I present to support each case? Would it be sufficient to tell that few hundred users find it convenient, and so do Grid m/w developers and site owners?
On one level, it'd be more relevant to us if the concept was of use to multiple grid middleware or job management systems. There is no need for standardization of the term if all those few hundred users are using the same system. :^) On the other hand, I'm sure I do not understand what you mean by runtime environment. While I have my own interpretations of the term, the way you talk about it does not match up at all with any way I would so I suspect you're talking about something different. We need your help here!
b) This should be done by wrapping the JSDL singletons inside some larger XML dialect that describes the relationship of the basic jobs to each other. Although we want to support workflows, we've always pushed the workflow bit of it out of scope so we can get agreement on the rest of everything. :^)
I don't think that describing several jobs in one script has anything to do with workflow. It's up to the workload management system to interpret it, but for the user's convenience it would be nice to include into JSDL a possibility to specify several jobs. No need for a "larger XML dialect", just one more super-element. Here's a use case: I want to submit 10000 jobs that differ only in one input parameter. I have a tool that generates JSDL; and I'd hate to fill my disk with 10000 small files. You are not going to create a dedicated workgroup to produce a two-line spec that describes JSDL concatenation, are you?
Ah, but that fits more with the concept of a service description; having a job running service that can take a vector of JSDL documents makes sense (and is a use case that perhaps ought to be forwarded to the Basic Execution Service WG) but that is completely external to the concept of a JSDL document. And anyway, there's no need to standardize everything (as I said before).
c) I think we're punting this one out to WS-Agreement (over a space of JSDL terms). It gets really complicated otherwise as you start to try to describe spaces of coupled terms...
Eh, nobody promised it's going to be easy :-) I understand that XML is just a markup language, not quite suited for task definition, because task description normally includes conditions "if then else", relations "and", "or", and negations "not". For example, "buy X amount of apples if they are red, else buy Y amount of pears and Z amount of bananas". This is a single task, these are not separate jobs. It does not describe workflow, because it does not specify in which shop these apples or pears should be purchased (doesn't even say it should be the same one), or when, and not even the price. JSDL presently can't describe such a job. I don't even see how two separate job descriptions can be merged by another *XML* dialect into one - XML is not really made for it. In real life, I've had plenty of jobs like "if a site has outbound connectivity, stage in this, else stage in something different". Globus' RSL allows this, and I'm sure it's a part of job description, not workflow. It is an instruction for the execution site, not for the workload manager/broker.
We have been through many iterations on this topic. Initially, we had a complex combinatorial language for doing this. It was a mess. We then switched to profiles for doing this (look them up in previous versions of the spec if you're interested) which were much simpler, but they too were removed on the grounds that they were also hard to specify accurately. Where we are now is at the point where we are leaving that sort of thing to some other specification, such as WS-Ag over a space of terms defined by JSDL. Given that it appears that this will actually be sufficient to describe such things, why should we *independently* develop our own language for doing preferencing? That would feel like a horrible case of Not Invented Here, and would be poor use of our time. And JSDL as it stands is going to be useful for many people, even if it won't solve your particular problem without extension of some kind. Of course, it might actually be the case that in the future we should return to the concept of a preferencing language so that your requirements could be addressed within JSDL itself. The development of standards is in reality an ongoing process, and not a simple target. Donal.
participants (4)
-
Ali Anjomshoaa -
Andrew Stephen McGough -
Donal K. Fellows -
Oxana Smirnova