March 2005 - jsdl-wg - lists.ogf.org

my view on execution user and group
by Karl Czajkowski 08 Apr '05

08 Apr '05

The concrete use case I have from Globus is to indicate under which POSIX username a job should be executed. I see group (actually, default or primary group) as a reasonable extension of the concept, though we do not do that today. This use case is job configuration details, just like POSIX limits, environment variables, etc. It is important in situations where there is not a one-to-one mapping of global user identity (PKI subject) to local accounts for the GRAM service to apply, e.g. when a user has several role-specific accounts or temporary "scratch" accounts. Of course, such configuration values are subject to authorization checks in practice. I am not clear on whether this is the intended purpose of the existing user and group fields in the User section, but if it is not then I am not clear on what it is for at all... I admit my bias is towards thinking of the use of JSDL in distributed protocols like GRAM. I guess if we were to use it in the local "adapter" interface between the GRAM service and the local scheduler scripts, we might have a use for specifying the authenticated user name, which for GRAM would be a PKI subject name. This makes sense because the adapter scripts inherently trust GRAM; GRAM would reject the presence of such a field in the over-the-wire transmission of JSDL, since the user identification comes from the binding-level security mechanisms. I can see this kind of info belonging in a User section for the adapter case, but I still need the POSIX username in the executable section. karl -- Karl Czajkowski karlcz(a)univa.com

12 28

JSDL v0.9.5-01
by Michel Drescher 31 Mar '05

31 Mar '05

Guys, here're a couple of new and updated documents: draft-ggf-jsdl-spec-0.9.5-01.doc The JSDL specification document itself. Contains all changes and decisions from the last phone conference. jsdl-0.9.5-01.xsd The JSDL schema consistent (well, I hope so...) with the latest specification document. apps-posix-0.1.xsd The schema defining the POSIXApplication element. POSIXApplication-Example.xml A sample XML file using the POSIXApplication extension. I will post a new list of issues for the next phone conference tomorrow (I hope). Cheers, Michel

3 3

GGF 13 notes and further discussion
by Michel Drescher 31 Mar '05

31 Mar '05

Dear JSDL wranglers, from the four sessions on GGF I compiled a list of topics that are unclear to me. My comments etc. are in square brackets ("[ and "]). Please feel free to comment. Session 1 - Fig. 1: suggestion to do a different document with scoping/explanation if this is controversial - multi-job [i.e. NAREGI] scenarios use container reference mechanism to pick up the needed pieces. [This would require identifying name attributes that should be of type NCName so that the container can use QNames to refer to needed parts. Alternatively, XPath or XQuery are an option, although not really handy in this case, IMHO] Session 2 - Units - declare as QNames? [I thought we agreed that units vanish and frequencies, bandwidth and storage are given, either as float or integer, with a fixed unit like Hz or Byte, respectively. However, can't find this in the notes stored at GridForge.] - open content on data staging [What does that mean?] - ref/name: check tooling support [Standard Java toolkits, SAX and W3C DOM, support this. However, AFAIK we didn't really clearly decide on using this.] Session 3 - A tag to indicate what the client wants to be understood or not? Everything should be understood vs [Hmm... vs what? What did we decide?] - jsdl:Application xsd:any##other with cardinality 1 vs jsdl:ApplicationType with type xsd:any##other and list all applications that are defined separately [No decisions on that so far, I think. It intertwines with Igor's proposal.] - need some tie-in to acs wrt [with respect to?] application definitions - [and these] limits should be under application executable [so these are then basically part of the normative JSDL extensions, or are they supposed to be child elements of the jsdl:Application element which is the parent element of the future normative extensions?] - [and the] limits are not used for resource selection; they are in the environment Session 4 - Get rid of all String types? - Ranges implicitly define operators, i.e. between 'a' and 'b' - Discuss on the list which resource constraints are global total constraints and which are per process constraints. [Are there constraints that can be both? For example, One may constrain the job to use no more than 10 Gigabytes of physical memory, but each process must not consume more than 10 Megabytes of physical memory. Is this a valid use case?] Cheers, Michel

5 9

Topics for the upcoming phone conference
by Michel Drescher 31 Mar '05

31 Mar '05

Dear JSDL wranglers, this is a list of topics I would like to be decided on at the today's phone conference. (1) JobDefinition/@JSDLVersion attribute The version of the JSDP spec is uniquely defined elsewhere, and encoded in the namespace. I do not see any use of this attribute. (2) JobDefinition/JobIdentification/User/UserCredential The spec contains a comment that this element "... can be handdled through the standard extension mechanism." Let's decide on the phone conference to keep it or to drop it (and release it to the extension mechanism). (3) range values Karl and Stephen made a valuable proposal for a clear and efficient definition of range values: <lowerBound>xsd:integer</lowerBound> ? <upperBound>xsd:integer</upperBound> ? <exact>xsd:integer</exact> * <range> <lowerBound>xsd:integer</lowerBound> <upperBound>xsd:integer</upperBound> </range> * I propose to replace our current definition of a range value with this complex structure. (4) xsd:integer or xsd:double Partly touching topic 3, there's a discussion on wether to use integers or fraction numbers. I propose to use xsd:double together with an optional attribute "epsilon=xsd:double" for precision restrictions, changing the range type to <lowerBound epsilon="xsd:double"? >xsd:double</lowerBound> ? <upperBound epsilon="xsd:double"? >xsd:double</upperBound> ? <exact epsilon="xsd:double"? >xsd:double</exact> * <range> <lowerBound epsilon="xsd:double"? >xsd:double</lowerBound> <upperBound epsilon="xsd:double"? >xsd:double</upperBound> </range> * (5) (Non-)Critical extensions There's a discussion at the moment to tag particular elements of JSDL to be (non-)critical in terms of understandability and support, similar to the SOAP attribute "mustUnderstand=xsd:boolean". I propose to postpone this mechanism to after the first official JSDL release. (6) naming elements To promote reusage, elements of JSDL documents should be identifiable. An appropriate technique is using QNames. This requires the elements that we want to be reused to get a naming attribute of type xsd:NCName. I propose to use this technique to promote reusage. If we agree to use this, a follow-up action point will be assiged to identify the elements that need this new naming attribute and to propose a naming syntax. (7) Resource constraints global total and/or per process During GGF13, the issue came up that a resource can be defined to be total global or as per process. A use case may be to constrain a job to 10 Gigabytes of physical memory and at the same time to constrain the job's processes to consume no more than 10 Megabytes of physical memory. I propose to reflect this in JSDL expressis verbis rather to punt it out to an extension. If we agree on incorporating this, a follow-up action point will be the investigation and proposal of solution alternatives. (8) Comments and flames on the current specification document Although this is very short term, I attached the current latest version of the spec document - unofficial as I am not the official editor! - in which I tried to reflect all the changes we agreed on at GGF13. It was quite much, so expect to face errors in what I created. Cheers, Michel

1 1

my view on "user credentials"
by Karl Czajkowski 30 Mar '05

30 Mar '05

I don't disagree that user credentials will be important for many jobs. However, I disagree that a type and semantics-free UserCredential field, as in the current draft, actually helps. I think a consumer of a JSDL document needs to know two things to make use of credentials: 1) what is it, and 2) what is it for. I think it is wishful thinking to say there is one generic user credential category and the consumer can divine the rest from the value itself. If this is so, we might as well put this expressive value in the xsd:any##other slot as an extension (understood by some, but not all, consumers). For example, in WS-GRAM for GT4, we do not pass around credentials per se, but we do pass around references to credentials (the actual credentials are moved ahead of time by out-of-band means relative to WS-GRAM). Because each of these references is of the same type (and referring to the same type of credential: our GSI proxies), we have separate fields in the WS-GRAM job language to designate the purpose of each one: one to put in the job's environment (as a file), one for WS-GRAM to use when invoking our RFT file transfer service, and a third to pass through (by reference) to the RFT service itself (which it then uses to authenticate with GridFTP). We would have to use these wrappers in the JSDL transliteration, since "user credentials" is too abstract to actually convey the different meanings we have. I suspect that any meaningful "pass through" would have to do the same thing---designate _which_ target mechanism to pass the values to. It wouldn't help much if a JSDL consumer "passed" a Kerberos ticket in the file where we expect GSI proxies, or vice versa. karl -- Karl Czajkowski karlcz(a)univa.com

4 5

REPOST: Topics for the upcoming phone conference
by Michel Drescher 29 Mar '05

29 Mar '05

REPOST: Identical to the first attempt except the spec doc. The first mail seemed not to pass the ML software. Please obtain the JSDL specification document from Gridforge. ---------- SNIP ---------- SNIP ---------- SNIP ---------- SNIP ---------- Dear JSDL wranglers, this is a list of topics I would like to be decided on at the today's phone conference. (1) JobDefinition/@JSDLVersion attribute The version of the JSDP spec is uniquely defined elsewhere, and encoded in the namespace. I do not see any use of this attribute. (2) JobDefinition/JobIdentification/User/UserCredential The spec contains a comment that this element "... can be handdled through the standard extension mechanism." Let's decide on the phone conference to keep it or to drop it (and release it to the extension mechanism). (3) range values Karl and Stephen made a valuable proposal for a clear and efficient definition of range values: <lowerBound>xsd:integer</lowerBound> ? <upperBound>xsd:integer</upperBound> ? <exact>xsd:integer</exact> * <range> <lowerBound>xsd:integer</lowerBound> <upperBound>xsd:integer</upperBound> </range> * I propose to replace our current definition of a range value with this complex structure. (4) xsd:integer or xsd:double Partly touching topic 3, there's a discussion on wether to use integers or fraction numbers. I propose to use xsd:double together with an optional attribute "epsilon=xsd:double" for precision restrictions, changing the range type to <lowerBound epsilon="xsd:double"? >xsd:double</lowerBound> ? <upperBound epsilon="xsd:double"? >xsd:double</upperBound> ? <exact epsilon="xsd:double"? >xsd:double</exact> * <range> <lowerBound epsilon="xsd:double"? >xsd:double</lowerBound> <upperBound epsilon="xsd:double"? >xsd:double</upperBound> </range> * (5) (Non-)Critical extensions There's a discussion at the moment to tag particular elements of JSDL to be (non-)critical in terms of understandability and support, similar to the SOAP attribute "mustUnderstand=xsd:boolean". I propose to postpone this mechanism to after the first official JSDL release. (6) naming elements To promote reusage, elements of JSDL documents should be identifiable. An appropriate technique is using QNames. This requires the elements that we want to be reused to get a naming attribute of type xsd:NCName. I propose to use this technique to promote reusage. If we agree to use this, a follow-up action point will be assiged to identify the elements that need this new naming attribute and to propose a naming syntax. (7) Resource constraints global total and/or per process During GGF13, the issue came up that a resource can be defined to be total global or as per process. A use case may be to constrain a job to 10 Gigabytes of physical memory and at the same time to constrain the job's processes to consume no more than 10 Megabytes of physical memory. I propose to reflect this in JSDL expressis verbis rather to punt it out to an extension. If we agree on incorporating this, a follow-up action point will be the investigation and proposal of solution alternatives. (8) Comments and flames on the current specification document Although this is very short term, I attached the current latest version of the spec document - unofficial as I am not the official editor! - in which I tried to reflect all the changes we agreed on at GGF13. It was quite much, so expect to face errors in what I created. Cheers, Michel

2 1

JSDL: Spec cleanup
by Ali Anjomshoaa 29 Mar '05

29 Mar '05

Hi all, thanks to Michel we have a cleaner version of the spec following GGF13 with some of the issues answered. Michel still has the pen and will be bringing an issues list to today's telecon. The spec is at: https://forge.gridforum.org/projects/jsdl-wg/document/draft-ggf-jsdl-spec/e… I propose that any outstanding issues from GGF13 be added to the spec, incrementing the double digits at the end of the version number at each iteration for this purpose. i.e. 0.9.5-00 to 0.9.5-01 etc. Any new additions to the spec (will have to get past Darren first [good luck!] 8^) ) should increment the last digit of the version number, i.e. 0.9.6 next. Cheers and take care, Ali Michel, pen goes to Andreas at the end of today for him to review the spec on the flight back home :) (The movies on the flight back to Tokyo are not great, I checked them out). -- ---------------------------------------------------- |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 -------------------------------------------------------------

2 1

FW: JSDL Meeting
by Bill Harris 29 Mar '05

29 Mar '05

William Harris Program Architect Oryx follow me - 800 281 6462 Inside cadence 88 202 6462 Cell Phone 801 301 2744 You have been invited to attend a Microsoft Office Live Meeting. At the time of the meeting, click on the following link to attend. http://www.placeware.com/cc/cadence/join?id=RWZ334&role=attend Subject: JSDL Meeting When: Tuesday, Mar 29, 2005 8:00 AM (MST) Scheduled to Occur: Once Duration: 1 Hour 30 Minutes Audio Information: 1-800-933-3594 ext 3000 pin: 6444 Click to add to your Outlook calendar: http://www.placeware.com/cc/cadence/meetingICS?id=RWZ334&role=attend&i=i .ics Alternate Attend Instructions: Go to: http://www.placeware.com/cc/cadence/join Your Name: (enter your name) Meeting ID: RWZ334 Dial In Numbers >Phone 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

2 1

drop User section?
by Karl Czajkowski 21 Mar '05

21 Mar '05

I had a thought on the flight home... isn't the user and group naming really part of the POSIX executable-application type, just like the limits turned out to be? [A side comment is that they are mislabled for POSIX: userName should be a string, and UserID if it exists should be a number, etc.] If we move them to the type-specific App syntax, the User section would become empty (since we already scoped away the userCredential element). I would advocate doing this and "garbage collecting" the User element from the spec 1.0, but I am certain I do not understand others' use cases surrounding this element. Any thoughts? karl -- Karl Czajkowski karlcz(a)univa.com

2 1

range value type
by Karl Czajkowski 19 Mar '05

19 Mar '05

Before I left Seoul, Stephen showed me a simple solution that was structurally along the lines of what I imagined for the range value element type. RANGE-VALUE COMPLEX TYPE PSUEDO-SCHEMA ---------------------------------------- It is very straightforward in terms of writing XSD. With some changes I recommend, it would look like this as a sequence: <...> <lowerBound>xsd:integer</lowerBound> ? <upperBound>xsd:integer</upperBound> ? <exact>xsd:integer</exact> * <range> <lowerBound>xsd:integer</lowerBound> <upperBound>xsd:integer</upperBound> </range> * </...> I have changed the names of the pieces from what I think Stephen showed me, in order to try to make their meaning as obvious as possible. The whole element is more or less a disjunction of its expression parts, but please note below the special treatment of the optional semi-space constraints (the top-level lower/upper bounds)... they are treated identically to a regular range element if both are specified and only act as true semi-spaces when one is omitted. However, all other exact and range expressions are treated independentally (as a true disjunction). The alternatives to this that I came up with all seemed unsatisfactory: 1) make it a complete disjunction, meaning any value over the lower bound OR under the upper bound is in range. 2) other hybrid conjunctions, meaning multiple bounds, ranges, and/or exact expressions have to match. INTEGER OR FLOATING-POINT REPRESENTATION ----------------------------------------- We had discussed using xsd:integer and this implies that any use of this type must just define the "base" units that are being counted. The only problem in our base terms is (cpu-)time, where I wonder if we are better off using a floating-point type to allow the base units to be seconds and still allow fractional second specification. Choosing some specoific fractional second as the base unit seems unappealing to me. If we provide a floating point/fractional version, I think there needs to be an optional attribute on the exact element to specify a precision or epsilon value for equality tests, e.g. <exact jsdl:precision="0.001">3.1415927...</exact> could match anything in the range (3.1405927..., 3.1425927...). Or, the consumer could treat it as undefined and do something appropriate if a precision is specified which it cannot support. Perhaps a simpler solution is to stick with arbitrary length integers and add an optional divisor attribute that defaults to 1: <exact jsdl:divisor="100000">314159</exact> which would be exactly 3.14159 in decimal fractions? Of course, a different divisor like "1024" could be used for binary fractions. I am not a numerical analyst so I would prefer we bounce any such proposal off of several before adopting it. SEMANTICS ------------------------------------------ The matching semantics would be as follows for an element of this type: let boolean "L" and "U" be whether lower/upper bound values are specified; let integer "l" and "u" be lower/upper bound values respectively let E be { e | e is specified in an exact element } let R be { <l,u> | <l,u> is specified in a range element } in_range(x) = (!L || l <= x) && (!U || x <= u) || there exists e in E such that x = e || there exists <l,u> in R such that l <= x <= u. INCLUSIVE VERSUS EXCLUSIVE RANGES ----------------------------------------- Also, I suggest that we place an optional attribute in the boundary elements: jsdl:exclusiveBound=xsd:boolean with default false, meaning that by default the range of acceptable values includes the boundary value in the element body. Setting it to true would mean that the boundary value is not part of the range. This supports any meaning captured before in the operator enumeration, I think. A minor note is that the elements have to appear in the sequence order, which I argue is a good thing for machine-machine communication as the parse tree will yield three monomorphic arrays of values with clear meanings, rather than one polymorphic array that the consumer has to traverse. karl -- Karl Czajkowski karlcz(a)univa.com

2 2