- jsdl-wg - lists.ogf.org

JSDL: Updates
by Ali Anjomshoaa 06 May '05

06 May '05

Hi everyone, yesterday's telecon minutes are now on GridForge: https://forge.gridforum.org/projects/jsdl-wg/document/Minutes_-_2005-05-03/… PLEASE note that next week's telecon starts an hour earlier and goes on for 2 hours, starting at: 06:00 PST 07:00 MST 08:00 CST 09:00 EST 14:00 BST 15:00 CET 22:00 JST Trackers updated to reflect minutes from yesterday's telecon. Remember, this week's the big push. Next week we're closing down the issues for v1.0. PLEASE ALL READ THE SPEC. Many thanks in advance. Cheers and take care, Ali -- ---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali(a)epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------

3 4

JSDL compliance levels
by Michel Drescher 04 May '05

04 May '05

Folks, I got the assignment to the following two action points from last week's phone conference: >> 8) JSDL compliance levels >> How much of jsdl a system must support, not just process. >> Probably a topic for later. >> >> 9) The statement "If not supported then the consuming system MUST >> reject the document." needs a bit more explanation or re-write To solve these action points, I refer to the specification document (v0.8.5-02) ch 2 "Notational conventions". I propose to replace the chapter's last three paragraphs (the text after table 1) with the following paragraphs: "The term JSDL documentrefers to a XML document that has been created following this specification. It is a schema instance document derived from the normative schema definition inAppendix 2:Normative Schema. The terms JSDL element and JSDL attribute indicate that the corresponding language construct is represented as an XML element and XML attribute in a JSDL document. The key word presentrefers to a construct being present in a JSDL document. The key word support refers to a consuming system being able to apply the following functions to a JSDL element or JSDL attribute: · Parse the JSDL element or JSDL attribute into a DOM tree · Validate the parsed DOM tree against the appropriate schema(s) · Interpret the JSDL element or attribute and assign the semantics according to this specification. The JSDL specification does not require the consuming system to actually implement the semantics of JSDL elements and attributes, so that the described job is executed on a computing system. A consuming system MUST support all normative JSDL elements and JSDL attributes. If a consuming system implements JSDL, it MUST implement all defined JSDL elements and attributes. This allows not only systems that execute jobs but also systems that provide higher level services, for example job broker, super scheduling systems (that possibly change JSDL documents before they get submitted to lower level job execution systems), etc." Note: The last paragraph possibly fits better in a JSDL primer document. This way any consuming system that deals with JSDL must support the defined JSDL elements and attributes, but it does not need to "ground" or "incarnate" or even execute a JSDL job. But if it implements JSDDL, then all JSDL elements and attributes must be implemented. So this basically eliminates any JSDL compliance levels. As we already reduced JSDL to the lowest common denominator, there is no need of compliance levels at all - at least for the moment. The consequence would be that we can delete all these "If not supported then ... " sentences. Cheers, Michel

2 1

Action Item 26, Tracker 1391
by Donal K. Fellows 03 May '05

03 May '05

Issue 26: Normative Reference for POSIX: ISO/IEC 9945:2003, Portable Operating System Interface, version 3 [Note: Not online, but thumpingly definitive!] Tracker 1391: Semantics of RangeValueType Adapted from Karl's mail message, please find attached document fragment to be inserted between the pseudoschema for the document and the example. Donal.

1 0

Meeting minutes May 2
by Darren Pulsipher 03 May '05

03 May '05

May 2, 2005 Attendees Darren Steve Ali Bill Donal Michel Agenda Action Items from last call Document Status =============================================== Other ----- Possible JSDL meeting to go with the OGSA F2F meeting in London. Agenda & Minutes ---------------- 5) Section 3 (spec doc) general revision and polishing up - To be done... - Action: Andreas - Owners for: Glossary : Extending JSDL --> On Going --> On Going --> On Going 6) Update explanation for jsdl:other usage - jsdl:other is the value for e.g. other arch and OS name etc. - Have defined this and behaviours - have to be able to process it and must reject the document if can't be processed. - To add extra information that is allowed to be ignored if can't be processed, but, jsdl:any can't be ignored. - Section 4.2 - placeholder (maybe better in the Extending JSDL section). --> Action: Steve (with Michel) - as number 17 --> On Going (03-May-2005) --> On Going (Almost Done) 8) JSDL compliance levels How much of jsdl a system must support, not just process. Probably a topic for later. - Placeholder, will come up later! [DONE] - Action: Michel --> Action: ALL to review Michel's e-mail to list: JSDL compliance levels http://www-unix.gridforum.org/mail_archive/jsdl-wg/2005/04/msg00111.html --> Action: Ali to edit Michel's proposed entry (03-May-2005) 9) The statement "If not supported then the consuming system MUST reject the document." needs a bit more explanation or re-write. - Related to number 8 above. - Refer to notational convention [DONE] - Action: Michel --> Action: ALL to review Michel's e-mail to list: JSDL compliance levels http://www-unix.gridforum.org/mail_archive/jsdl-wg/2005/04/msg00111.html --> Action: Ali to edit Michel's proposed entry (03-May-2005) 11) Filesystem name and type and filesystem reference in DataStaging - This needs to be specified? Needs more explanation? - Action: Andreas - FileSystemID changed to FileSystemName - Define well known filesystem names: HOME and TMP --> On Going --> On Going --> On Going *** 12) Mountpoint environment variable. Is the current approach ok, or should we provide a separate mechanism, e.g, a tag that if present provides the name of the environment variable in which the MountPoint value must be present. - If a Mountpoint environment variable is not specified, then the name of the filesystem is used for the value of the env var. - Action: ALL to review spec section 5.5.12 and get back to the list - Issue to be discussed on the list. --> On Going --> On Going --> On Going 14) DRMAA use case for defining filenames. We have to at least be able to show an example of how to define and stage out an <Output> file. - Action: Andreas [DONE]- Action: Donal to suggest alternative - Action: ALL to review Donal's suggestion on the mailing list. - Action: Donal to chase this on the list... --> On Going --> On Going 16) Process Topology needs review. In particular are the examples ok or not, are the definition correct and so on. Delete the yellow comments once that is done. Not sure if we should define the precise allocation behaviour or allow for that to be defined instead. - Action: ALL to review this section (Section 6 in 0.9.5-01). - ProcessCount to be put back into POSIX Application. - ProcessCountLimit in the POSIX Application. [DONE] --> Action: Chris to bring issues to list if any - Action: ALL to review discussion on this on the list - Action: Karl to send summary of discussion to the list - Action: Andreas to put final recommendation from Karl's summary in the spec. --> On Going --> On Going --> On Going 17) Section "Extending JSDL" needs an owner. I expect this section to be about 1 page long so should not be too much trouble. - Action: Steve (with Michel as wingman) --> On Going --> On Going (03-May-2005) --> On Going (Almost Done) 19) Re-check terminology for process topology and delete comments - Part of 16 Review --> See 16 above - On Going 24) Complete author information (see my entry as reference) - Leave to last... Placeholder --> Action: Ali to pick this up. --> On Going --> On Going --> On Going 25) Update contributors and acknowledgements - Leave to last... Placeholder --> Action: Ali to pick this up. --> On Going --> On Going --> On Going 26) Complete list of Normative references, e.g., CIM is still missing. - Leave to last... Placeholder --> One for CIM (http://www.dmtf.org/standards/cim/) version 2.8 --> Action: Donal, pass ref for lists from CIM to Andreas. - Action: Donal - Add reference for POSIX. --> On Going --> On Going --> On Going 31) Complete example sub-sections - Need examples for elements. --> On Going --> On Going --> On Going v1.0 GridForge Trackers ----------------- 1271 - post-1.0 1272 - post-1.0 1273 - DONE 1275 - Steve 1277 - DONE, CLOSE 1279 - DONE 1280 - DONE 1281 - DONE 1282 - post-1.0 1283 - post-1.0 1284 - post-1.0 1285 - Michel: Andreas' Intro Slides 1286 - post-1.0 1310 - DONE 1326 - DONE 1327 - Ali: Andreas' Intro Slides 1330 - post-1.0 1331 - DONE 1332 - post-1.0 1334 - DONE 1335 - DONE 1358 - post-1.0 1391 - Donal

1 0

Web conference for May 3
by Darren Pulsipher 03 May '05

03 May '05

Darren Pulsipher has invited you to present at a Microsoft Office Live Meeting. Join Meeting <https://www.livemeeting.com/cc/xangoit/join?id=KC2MK6&role=present&pw=Q %5E%21m%29%26%264x> Meeting Details Subject: JSDL Meeting URL: https://www.livemeeting.com/cc/xangoit/join Meeting ID: KC2MK6 Presenter Key: Q^!m)&&4x Role: Presenter This Office Live Meeting invitation is a personal invitation meant only for you. It should not be forwarded. If you received this email by mistake or require Live Meeting Assistance, please refer to the Live Meeting Assistance Center at http://r.office.microsoft.com/r/rlidLiveMeeting?p1=7&p2=en_US&p3=LMInfo& p4=support

1 0

RE: JSDL Meeting on May 3, 2005
by Bill Harris 02 May '05

02 May '05

Audio for meeting on Tuesday information 1 800-933-3594 at message dial 3000 id is 6444 and confirmed ;-) Talk to you in the morning William Harris Program Architect Oryx follow me - 800 281 6462 Inside cadence 88 202 6462 Cell Phone 801 301 2744 The contact details are: Dial In Numbers: Belgium - 0800-7053 Bezeq - 1-800-940-1786 France - 0800-903109 Germany - 0800-1815765 Hong Kong - 800-968932 Italy - 800874509 Japan - 00531123656 Korea-Tele - 00798-14-800-0512 Netherlands - 0800-0225447 Singapore - 800-1200766 Sweden - 020-7905043 Taiwan - 00801-13-8546 UK - 0800961294 US - 800-933-3594 --> ext 3000 pin: 6444 The telecom time is: Tue May 3rd this week 07:00 PST 08:00 MST 09:00 CST 10:00 EST 15:00 BST 16:00 CET 23:00 JST

1 0

jsdl version 1 draft 18 (aka 0.9.5-03)
by Andreas Savva 02 May '05

02 May '05

New snapshots of spec and schemas are on gridforge: https://forge.gridforum.org/projects/jsdl-wg/document/draft-ggf-jsdl-spec/e… https://forge.gridforum.org/projects/jsdl-wg/document/jsdl.xsd/en/12 https://forge.gridforum.org/projects/jsdl-wg/document/jsdl-posix.xsd/en/2 There are still a number of inconsistencies due to open issues etc. I changed the numbering in this version as I described in the last release email (since nobody complained about it....). So this is "Version 1.0, draft 18". Summary of changes: ------------------- 0. changed numbering to version 1.0 (draft XX) and XX is the version number on gridforge (as proposed in last release email). 1. hostname to candidatehost change (spec and schema: Steve) 2. namespace changes (table in spec and schemas: Michel) 3. deleted "octets of bits" (spec) 4. deleted appendix: Translation table -> to separate doc (spec) 5. deleted appendix: JSDL examples -> to separate doc (spec) 6. Updated limits text (spec: Donal) 7. Deleted User and added UserName and GroupName to POSIXApplication (spec and schema) 8. deleted 'prepend' (spec and schema) 9. changed FileSystemID to FileSystemName (spec and schema) 10. CIM reference, cross-checked values in operating system and made sure they are 'correct' relative to the referenced cim version (2.9). I deleted a couple of values as a result. (As Donal mentioned we are not using CIM for the values of Processor Architectures. Do we want to use CIM or are we ok with defining our own values. There is a minor inconsistency in informative text.) 11. updated fig.1 & 2 (but fig 2 is still needs some work) 12. Other minor changes (incl accepting some older changes) Sorry for being a bit late with this snapshot. -- Andreas Savva Fujitsu Laboratories Ltd

1 0

a couple of questions
by Ariel Oleksiak 29 Apr '05

29 Apr '05

Hi All, That's me again. Please find another portion of questions and comments concerning the latest versions of JSDL specification and schema. These issues arisen mainly when we were trying to map JSDL to other job description languages. 1. In one of my previous emails I asked about specification of a directory in the DataStaging element and I got the answer that this is possible. Therefore, in my opinion, what we need is the attribute which distinguishes between regular file and a directory. I think that a scheduler may often need this knowledge to perform data staging (e.g. it may have to know whether a given logical name is the name of file or directory in order to call appropriate methods of a data management system). 2. I guess the NetworkBandwidth element defines the maximal bandwidth of the networking interface for a given resource. Such a metric is rather useless in a resource selection process because indeed only the actual bandwith between two nodes is really important. So didn't you think about the element defining bandwith between two nodes, e.g. containing an attribute to specify the second node? 3. Some time ago we discussed defining of software dependencies, e.g. necessary libraries etc. and I sent some simple use-cases. I do not see this element in the spec. Have you come to the conclusion that this is not general enough? 4. What is the meaning of the "other" value in the list of OSs, processor architectures etc.? Does it mean that (i) a scheduler has to select resources limited to those having OS OTHER than the remaining OSs from the list or (ii) that a certain OS, not included in the list, is required and its exact name is included in an additional element (which one?). In my opinion the latter is more rational (actually I don't see any use case for the former) but, if so, how this OS should be specified - using the Description element, extension? 5. The next question is related to the semantics of resource requirements in JSDL. Are resource requirements limited to required amounts of resources available for user's application (e.g. free CPUs, free memory etc.) in a given point of time or they also enable a user to specify required total amounts of resources (e.g. total number of CPUs, total virtual memory etc.)? Of course the former (dynamic) values are much more important during resource selection, however, information about some of them may not be available in all grid environments. Anyway this distinction must be clearly defined. 6. I see that units and operators attributes disappeared from the schema. I understand that operators can be expressed using RangeValueType and units are defined in the specification now? 7. It is not clear for me what is the difference between Range elements and Upper/LowerBoundedRange in the RangeValueType. Sorry if it has been already explained elsewhere. 8. I cannot find a way to specify a type of application in terms of its architecture (single, mpi etc.). I suppose that you consider it as too specific and as a possible extension or maybe this is an oversight? Thanks, Ariel

2 1

CIM Reference (Again)
by Donal K. Fellows 27 Apr '05

27 Apr '05

The CIM reference I was using at the F2F was a preliminary release of CIM 2.9, and currently we're only using the operating system types from them (in their human-readable versions[*]). There is also a processor typing model available, but it's just about unusable from our PoV because CIM does not support partial order relations on its enumeration types. (The problem is also there with OSes, but the amount of cross-emulation is much less.) The enumeration was taken from the ValueMap for System -> Operating System -> CIM_OperatingSystem -> OSType part of the overall model (Device sub-model, Operating System page, CIM_OperatingSystem class, OSType field), though it is necessary to read the MOFs or the XML to actually get the values. (Messy!) The processor part of the model would be the ValueMap from Device -> Processors -> Processor -> Family, except I find it hard to see many people being happy at distinguishing between "AMD Athlon(TM) 64 Processor Family" and "AMD Opteron(TM) Processor Family" for almost all applications! The reference to the final version of CIM 2.9.0 is at http://www.dmtf.org/standards/cim/cim_schema_v29 but I actually used http://www.dmtf.org/standards/cim/cim_schema_v29_prelim if that matters. Note that as far as we're concerned, I think updates to the list of OS types shouldn't be a problem. Donal. [* The core model is actually numeric, but we really don't want to go that route; it overexposes the underlying implementation details. ]

1 0

JSDL: Today's telecon minutes
by Ali Anjomshoaa 26 Apr '05

26 Apr '05

Hi everyone, today's telecon minutes are on GridForge at: https://forge.gridforum.org/projects/jsdl-wg/document/Minutes_-_2005-04-26/… For those on the call, your actions are in the minutes. Please ask for help on the list with feedback or effort. Thanks everyone. Cheers and take care, Ali -- ---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali(a)epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------

1 0