- ogsa-hpcp-wg - lists.ogf.org

HPC Profile meeting *ONLY* on tomorrow (Wed), not Thursday too
by Marty Humphrey 12 Sep '06

12 Sep '06

Folks, Originally, we scheduled TWO meetings for the HPC Profile WG -- one for the GGF proper and the other for the subsequent F2F. We did this because we felt that we potentially had a lot to discuss. Over the past month or two, many of these issues have either (a) been resolved, or (b) properly delegated to the JSDL WG or BES WG as appropriate. In other words, we feel that it is appropriate to only have *ONE* session instead of two. Therefore, we are *CANCELING* the Thursday session in the OGSA F2F (which was supposed to meet Thursday at 3:30-5pm). Note that we decided to cancel Thursday's meeting as opposed to tomorrow's meeting because (a) we believe that discussions in the main GGF session would result in a larger and broader audience, and (b) both Marvin and I would have had to rush out of the meeting Thursday evening to try to satisfy travel constraints. We look forward to a productive meeting in our main GGF session, which is tomorrow 1:30 - 3:30 in 158 A-B. -- Marty Marty Humphrey Assistant Professor Department of Computer Science University of Virginia

1 0

Update to HPC Profile Application draft
by Christopher Smith 07 Sep '06

07 Sep '06

I've posted an update for the HPC Profile Application extension to gridforge. https://forge.gridforum.org/sf/go/doc13735?nav=1 I've incorporated Donal's edits, and have made other edits due to his comments. Three items are still open for discussion: 1. Behaviour when WorkingDirectory is specified, but the directory doesn't exist. I've added text to say that this should cause a fault to be raised. 2. Relationship between WallClockLimit and JSDL Resources section. I've added text that the WallClockLimit may be used by the consuming system as part of the resource selection criteria. 3. Format for directory and file names. Which delimiter is to be accepted? For fully qualified path names, I guess we should accept "drive letter qualified" paths (e.g. c:\my\directory\path) in addition to simple delimiter started paths. Should UNC path names be accepted? I would propose to add text accepting '/' as a delimiter, and allowing all three of the above for fully qualified paths. -- Chris

2 1

Minutes for OGSA HPC Profile telecon (Aug 18 2006)
by humphrey＠cs.virginia.edu 07 Sep '06

07 Sep '06

[[ these will be uploaded to sourceforge shortly ]] OGSA HPC Profile Minutes Fri Aug 18 2006 Participants: Marty Humphrey (University of Virginia) Marvin Theimer (MSFT) Glenn Wasson (University of Virginia) Donal Fellows (University of Manchester) Minutes: Marty Humphrey * Summary of Actions: AI-HPCP-0818a: Donal Fellow to review HPC Profile Application. AI-HPCP-0818b: Marvin Theimer will add paragraph to HPC Basic Profile stating: "all other elements of the JSDL 1.0 MAY appear but MAY also result in a 'not implemented' fault, but only the list here must be supported" AI-HPCP-0818c: Marvin Theimer will add first draft of section 4 to HPC Basic Profile that restricts BES operations to singletons * Previous minutes: NONE (this is the first teleconference) * Review of Actions: NO Previous Actions (this is the first teleconference) * Discuss the State of BES -------------------------- Marvin Theimer has grabbed the pen on BES doc (plan: to send it out by Wednesday including refactoring: [1] arbitrary clients vs [2] sys admins; management would only have start and stop) (ie. Put query into the factory); Main thing: add fleshed-out extended state model (current draft: there WILL be an extended state model, and heres the basic one"). extend data-staging example so that Ian F and Dave S can see the details and/or are satisfied Glenn: factoring into two port types (or three: activity, factory, management: but Activity is not current in it), not going to be in an Appendix Interesting issue: what ultimately shows up in the activity management interface Glenn: seemed like from the base case that the only thing you would do from the interface is Cancel Marvin recapped his email to BES re: three renderings Claim: basics of BES are shaping up to be what we expected (shaping up in a good way) * HPC Profile Application Extension - JSDL extension for describing executables, etc. ------------------------------------------------------------------------------------- fairly far along, are we happy with whats in there? Consensus is yes, were happy. Next step is to have someone other than Chris to go through it to see if there are any details that they dont like. Donal: the document needs: which bits are the normative MUSTs AI-HPCP-0818a: Donal Fellow to review HPC Profile Application. Specifically to ensure that normative text use is correct. Also, adding normative text. Hopefully done before the next JSDL call on Wed. Goal: to get on the agenda for JSDL. Donal will contact Andreas to get on the JSDL WG agenda. * HPC Basic Profile ------------------- Issue: whats the style of writing this doc? How do the restrictions work? Previous discussion: do we really want to create a doc that only has MUSTs? Currently, the style is: "These are the elements that MUST be supported and all other aspects COULD be supported but you also might get a fault back." Consensus is that this is the best style. Missing: another paragraph : "all other elements of the JSDL 1.0 MAY appear but MAY also result in a 'not implemented' fault, but only the list here must be supported." Example: file system element. Glenn: I dont like the Strike-out approach because you need both docs. AI-HPCP-0818b: Marvin Theimer will add paragraph stating: "all other elements of the JSDL 1.0 MAY appear but MAY also result in a 'not implemented' fault, but only the list here must be supported." Donal says: probably want to add more text with regard to range values. E.g., it must support JSDL exact but the exact allows to specify what you mean by Exact. In the case of range values, you also want to specify to mandate the syntactic requirements of integer values. I.e., set-value resources or single value resources. If NOT "set", then go with "exact". Marvin: Do we want to, in the base case, restrict total cpu count to be exact? COnsensus in call is that this is tricky, because its arguably not as simple as we would like. Consider putting this issue in a tracker. This leaves section 5 of BESour only restriction is to eliminate required support for arrays. AI-HPCP-081c: Marvin Theimer will add first draft of section 4 that restricts BES operations to singletons. This will result in our first complete draft. He will add in a first draft of the security section. * Other news ------------ Donal: At the end of the OGSA call yesterday, it was mentioned that EMS and data people are looking to do a combined use case, based on the HPC Profile. We all agreed on the call that this was great news and we're anxious to work with them. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

9 18

Re: [ogsa-hpcp-wg] Revised version of BES draft specification
by Ian Foster 06 Sep '06

06 Sep '06

I can't be on the call tomorrow as I am at a conference in DC. Perhaps Peter Lane can make the call. Ian. At 11:29 AM 9/6/2006 -0700, Marvin Theimer wrote: >Content-Language: en-US >Content-Type: multipart/alternative; > >boundary="_000_8A89086DD69AD14899AD08D44A7F74021236D140DANAEXMSGC101Br_" > >Ian; > > > >I agree with your concern at least to the level that this needs to be >discussed and the material, if included, probably modified. I included it >in the draft as a place holder for future discussion. I think I also >added a tracker on the matter, but it was very late at night and I might >have forgotten to. > > > >This is a topic Id like to propose for discussion at tomorrows >teleconference call, if possible. > > > >Marvin. > > > >From: ogsa-hpcp-wg-bounces(a)ogf.org [mailto:ogsa-hpcp-wg-bounces@ogf.org] >On Behalf Of Ian Foster >Sent: Monday, September 04, 2006 8:05 PM >To: Mailing List for OGSA-HPCP-WG; Mailing List for OGSA-HPCP-WG; Peter G. >Lane >Cc: ogsa-bes-wg(a)ggf.org; ogsa-hpcp-wg(a)ggf.org >Subject: Re: [ogsa-hpcp-wg] Revised version of BES draft specification > > > >I'm concerned about the inclusion of the Appendix entitled "Container >Model." This looks like useful material that should be published, but I >don't believe it belongs in the BES specification. > > >At 06:30 PM 9/4/2006 -0500, Ian Foster wrote: > >I would like to claim the pen. > >Ian. > >At 02:56 PM 9/2/2006 -0600, Peter G. Lane wrote: > >I'm done with my changes for the moment. The sections I was tasked to fill >out were mostly done, so it was mostly just polish. I also did a lot of >polishing to the operations, especially the schemas and WSDLs. I'd really >appreciate it if people could look at this version before I put it up on >the BES documents page. I want to make sure everybody's ok with the >changes I made. Here is a general overview of what I did: > >- Changed all references to GetActivyStatus and GetActivitiesStatus (the >document inconsistently had both) to GetActivityStatuses to be both self >consistent and consistent with GetActivityDocuments (according to my >dictionary, this is the correct plural of "status"). >- Added myself to the authors list. >- Fixed some xsd:any element declarations in operation wrapper types. >- Removed "Type" suffix from all instance elements since they are not >complexTypes. >- General clean up of the schema to be consistent and more readable. >- Removed all minOccurs="1" and maxOccurs="1" element attributes since >these values are the default. >- Fixed the s12:Fault element declarations. >- Removed duplicate LocalResourceManagerType element from >BasicResourceAttributesDocumentType (also exists in >BESResourceAttributesDocumentType). >- Added fault element to the GetActivityDocuments response type >- Added explicit wsa:Action attributes to all input and output operation >elements >- Updated the non-normative message examples > >I should note that the section numbers seem quite messed up. Somebody who >has a better idea of where things are supposed to fit ought to make sure >the numbers are ok. I would have assumed that Word would take care of this >automatically, but I guess not. > >Peter > > > >Content-Type: application/x-pkcs7-signature; name="smime.p7s" >Content-Disposition: attachment; filename="smime.p7s" >Content-Description: S/MIME Cryptographic Signature > >0 *H÷ > 010 0 *H÷ > P0¦0 Ñ0 > *H÷ >0i10 &ò,dorg10 &ò,dDOEGrids1 0UCertificate Authorities10U >DOEGrids CA 10 >051111152456Z >061111152456Z0^10 &ò,dorg10 &ò,ddoegrids10 >UPeople10UPeter G Lane 3642430"0 > *H÷ >0»ÔäÓÎ<¹ÖM >Ù3¶é=vU5âHÚñz®w7¼AhÂÃCñ;Ud¥°%ólñß=hýÙmE[w"é!My"c<2n[dÿÞ¢fo®°5¶anWAoØÁaé:Yñbx=ÕÕ4ÝB©"L5@`?ÛÐ©Nk2Åûü°ÿ·Þø·=D` >É¦9æÑ³ùo¸ðÝ±Áä1éß¡ÔF®r8"[])}QJn>Õuï¯j^¸[Ñ½1¸Ùç5èfãIÞoÝÎ?~Ù|CUäÅÓº;ùDy£c0a0 >`HøBà0Uÿð0U#0Ên¤8]BÔ1ÛÙ >]0U0lane(a)mcs.anl.gov0 > *H÷ >|Âr >¹vçÞW29z¾MbÎí³þÐãsaTÝrÁx¶ >±<ð<]@Ígzñö#¬ûúÅÜpxÜÝ¯f^b"ÀcÖcX>¡ÞD"kPíòëSØ?ú¾=æ#Q¼×æóhé[½¯´á0{¡i >õâÀßó¨¾Î<â <üW0Pdæ-±Ú-Ðâ >Z}ÖÏ*%D6¸=iSpJ|µ0rÀi'LK×uOÌ/l ÆcÖFØ*í«ÁÐ`c >äÃ(¯¯â`G®{©æÐ>Ý¾_×÷4¯ÕÙ1÷ø ¦¢=ÿ9ÊJæðé¸¾ç0¦0 Ñ0 > *H÷ >0i10 &ò,dorg10 &ò,dDOEGrids1 0UCertificate Authorities10U >DOEGrids CA 10 >051111152456Z >061111152456Z0^10 &ò,dorg10 &ò,ddoegrids10 >UPeople10UPeter G Lane 3642430"0 > *H÷ >0»ÔäÓÎ<¹ÖM >Ù3¶é=vU5âHÚñz®w7¼AhÂÃCñ;Ud¥°%ólñß=hýÙmE[w"é!My"c<2n[dÿÞ¢fo®°5¶anWAoØÁaé:Yñbx=ÕÕ4ÝB©"L5@`?ÛÐ©Nk2Åûü°ÿ·Þø·=D` >É¦9æÑ³ùo¸ðÝ±Áä1éß¡ÔF®r8"[])}QJn>Õuï¯j^¸[Ñ½1¸Ùç5èfãIÞoÝÎ?~Ù|CUäÅÓº;ùDy£c0a0 >`HøBà0Uÿð0U#0Ên¤8]BÔ1ÛÙ >]0U0lane(a)mcs.anl.gov0 > *H÷ >|Âr >¹vçÞW29z¾MbÎí³þÐãsaTÝrÁx¶ >±<ð<]@Ígzñö#¬ûúÅÜpxÜÝ¯f^b"ÀcÖcX>¡ÞD"kPíòëSØ?ú¾=æ#Q¼×æóhé[½¯´á0{¡i >õâÀßó¨¾Î<â <üW0Pdæ-±Ú-Ðâ >Z}ÖÏ*%D6¸=iSpJ|µ0rÀi'LK×uOÌ/l ÆcÖFØ*í«ÁÐ`c >äÃ(¯¯â`G®{©æÐ>Ý¾_×÷4¯ÕÙ1÷ø ¦¢=ÿ9ÊJæðé¸¾ç0ø0à 0 > *H÷ >0u10 &ò,dnet10 &ò,dES10UESnet1 0UCertificate >Authorities10UESnet Root CA 10 >021205080000Z >080110080000Z0i10 &ò,dorg10 &ò,dDOEGrids1 0UCertificate >Authorities10U >DOEGrids CA 10"0 > *H÷ >0´õÖ#a£Û>fµ¸o²ß-jmr¢Èq÷¼.ËÛcâ,-ÿY"×d >n1ËË.kÙÉÊíºdÌ´ë`ß >IÔwÂáQHWKTo@lÖ²yþúq¥BÍ~!t.7«8ôÜ5ö^Õ6ZÝí\ö·<5y9%þgì²KÅ!k´ÈÍÈ_ú}!Á£Íç|%wÓÖøcC¸vQ[7ÎrÎoÓ³µQýlW7¾ÌÅlpk]-ðÖïcNßªæÑ-tö«Û°ÙZ®Ño«<¦¤@ºJ{Mø]Ì{êROÅÆQZ)ùcw¯?K£00 >`HøB0UÿÆ0UÊn¤8]BÔ1ÛÙ >]0U#0¼]MH/ø5Y«\K>Ñ²:ê0Uÿ0ÿ0%U0DOEGrids-CA-1@doegrids.org0 > *H÷ >*;b>3p{)5V#±¶(=vÎ53¡¿(B7â >xQ{Â¤´`-#gÝKøj1q.ãë8ÓÕ¶ÙðRa5Ôj½BF¹ÃãÚ]=Â£3NQëji_gkÝE´´ªxýÊ^Í¸¿´þBkêÛÎ¹ñî¥@Çwè¨(v¶c¶JÊHÕdjÝ1rI¥ÿ¿£°ôÎ¥½ÐÝ >u<iû²@x1îÀÑ¼¯;DÚê ©Zµk;>Õz[½TÙï<xG¸-*Õ#Å)eSÇ½º >·±ûþêß(ôüYy§@éÀGf¢åÿ.#A»1N0J0o0i10 &ò,dorg10 &ò,dDOEGrids1 >0UCertificate Authorities10U >DOEGrids CA 1Ñ0 ´0 *H÷ > 1 *H÷ >0 *H÷ > 1 >060902205636Z0# *H÷ > 1<úÍNþR[9£ì$2³S0R *H÷ > 1E0C0 *H÷ >0*H÷ >0 >*H÷ >@00 >*H÷ >(0~ 71q0o0i10 &ò,dorg10 &ò,dDOEGrids1 0UCertificate >Authorities10U >DOEGrids CA 1Ñ0*H÷ > 1q o0i10 &ò,dorg10 &ò,dDOEGrids1 0UCertificate > Authorities10U >DOEGrids CA 1Ñ0 > *H÷ >>ÇÏSm°dò;±Øþ--Ü|ÃËfï{qFé,±Çz¾ »UÔ®JÛ¢ÇLßHöá >ôDúWÉ±¹Æ¹öV¬µóïý2ÓÎ´5ò4§:¡²¸>bUVq ý¼®©ZøÔèO|ö«0 >:céA·Ðú%3äj1ÍGÍq&ºÞc >[ZÏÄ7§.FZY#É×¸X^¤lNxèSâWÃàêqØÔäÐçÜ*aÓêî/n3[m-Sí1p7-å¢:<üÎqµÅ9Ï >xFù<Èïâ;^¿t|G.¦Þÿ|0_6 >-- > ogsa-hpcp-wg mailing list > <mailto:ogsa-hpcp-wg@ogf.org>ogsa-hpcp-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg > > >_______________________________________________________________ >Ian Foster -- Weblog: ><http://ianfoster.typepad.com/>http://ianfoster.typepad.com >Computation Institute: <http://www.ci.uchicago.edu/>www.ci.uchicago.edu & >www.ci.anl.gov >Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 >Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 >Tel: 1 630 252 4619 --- Globus Alliance: ><http://www.globus.org/>www.globus.org > > >-- > ogsa-hpcp-wg mailing list > <mailto:ogsa-hpcp-wg@ogf.org>ogsa-hpcp-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg > >_______________________________________________________________ >Ian Foster -- Weblog: ><http://ianfoster.typepad.com/>http://ianfoster.typepad.com >Computation Institute: <http://www.ci.uchicago.edu/>www.ci.uchicago.edu & >www.ci.anl.gov >Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 >Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 >Tel: 1 630 252 4619 --- Globus Alliance: ><http://www.globus.org/>www.globus.org > > >-- > ogsa-hpcp-wg mailing list > ogsa-hpcp-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg _______________________________________________________________ Ian Foster -- Weblog: http://ianfoster.typepad.com Computation Institute: www.ci.uchicago.edu & www.ci.anl.gov Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org

2 1

Revised version of BES draft specification
by Marvin Theimer 06 Sep '06

06 Sep '06

Hi; I have finished all the edits that I intended to make and have uploaded my work to gridforge as version 22 of the BES draft document: https://forge.gridforum.org/sf/go/doc13783?nav=1 The document is also attached to this email. A summary of the changes I've made is the following: Refactored BES-Management and BES-Factory port types. Promoted Cancelled and Failed to first-class states in the base state diagram. Moved material in Appendix A on renderings to introduction. Changed names of some of the operations. Completely rewrote section 4 on the extensible state model, including adding more examples. Moved things around in sections 5 & 6 to reflect the refactored port types. Clarified the vector-length return values from GetActivitiesStatus, TerminateActivities, and GetActivityDocuments operations. Added a wrapper to the input argument to CreateActivity so that BES-specific inputs can be provided along-side a JSDL document. Clarified the semantics of TerminateActivities. Added an embrionic extensions section. Added myself to the author list. Fixed up the appendices to reflect the other changes to the document. Replaced the use of WS-BaseFault with Soap-1.2 faults. Added Ellen Stokes' container material as an appendix. I hereby relinquish the pen (and associated lock) on this document. Marvin.

3 5

Re: [ogsa-hpcp-wg] [OGSA-BES-WG] Revised version of BES draftspecification
by Ian Foster 06 Sep '06

06 Sep '06

Andrew: I have so far done the following things, after accepting all previous changes: * Re-inserted BES-Activity material, as agreed on a previous call * Removed a few remaining spurious references to WS-BaseFaults * Changed some occurences of "base state model" to "basic state model" for consistency * Various minor typographical changes. * Fixed up section numbering * Moved "security considerations" to the end, as is conventional I enclose version 24 and release the pen. More work is needed on the BES-Activity material. Ian. At 09:26 AM 9/5/2006 -0400, Andrew Grimshaw wrote: >Ian, > >What mods are you going to do? We had specific writing assignments from >last weeks call. The next thing to be done by Mark and Chris S. is to get >XML & WSDL stuff correct at the end of the document. We want to lock the >text, so we donât have to keep redoing the porttypes. > >A > > > >---------- >From: ogsa-bes-wg-bounces(a)ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On >Behalf Of Ian Foster >Sent: Monday, September 04, 2006 7:30 PM >To: Mailing List for OGSA-HPCP-WG; Peter G. Lane >Cc: ogsa-bes-wg(a)ggf.org; ogsa-hpcp-wg(a)ggf.org >Subject: Re: [OGSA-BES-WG] [ogsa-hpcp-wg] Revised version of BES >draftspecification > > > >I would like to claim the pen. > >Ian. > >At 02:56 PM 9/2/2006 -0600, Peter G. Lane wrote: > >I'm done with my changes for the moment. The sections I was tasked to fill >out were mostly done, so it was mostly just polish. I also did a lot of >polishing to the operations, especially the schemas and WSDLs. I'd really >appreciate it if people could look at this version before I put it up on >the BES documents page. I want to make sure everybody's ok with the >changes I made. Here is a general overview of what I did: > >- Changed all references to GetActivyStatus and GetActivitiesStatus (the >document inconsistently had both) to GetActivityStatuses to be both self >consistent and consistent with GetActivityDocuments (according to my >dictionary, this is the correct plural of "status"). >- Added myself to the authors list. >- Fixed some xsd:any element declarations in operation wrapper types. >- Removed "Type" suffix from all instance elements since they are not >complexTypes. >- General clean up of the schema to be consistent and more readable. >- Removed all minOccurs="1" and maxOccurs="1" element attributes since >these values are the default. >- Fixed the s12:Fault element declarations. >- Removed duplicate LocalResourceManagerType element from >BasicResourceAttributesDocumentType (also exists in >BESResourceAttributesDocumentType). >- Added fault element to the GetActivityDocuments response type >- Added explicit wsa:Action attributes to all input and output operation >elements >- Updated the non-normative message examples > >I should note that the section numbers seem quite messed up. Somebody who >has a better idea of where things are supposed to fit ought to make sure >the numbers are ok. I would have assumed that Word would take care of this >automatically, but I guess not. > >Peter > > > >Content-Type: application/x-pkcs7-signature; name="smime.p7s" >Content-Disposition: attachment; filename="smime.p7s" >Content-Description: S/MIME Cryptographic Signature > >0 *Hâ Hâ Ã· > 010 +0 *HÃ· > > P0Â¦0 Ã0 > > * HÃ· >0i10 â&âÃ²,dorg10 â&°âÃ²,dDOEGrids1 0UCertificate >Authorities10U >DOEGrids CA 10 >051111152456Z >061111152456Z0^10 â&âÃ²,dorg10 â&âÃ²,ddoegrids10 >UPeople10UPeter G Lane 3642430"0 > * HÃ· >0Â»ÃâÃ¤ÃÅÃ¤ÃÅÃ<Â¹ÃM >â¹Ã3Â¶Ã©=vU5Ã¢HÃÃ±zÂ®w7Â¼AhÃÃCÃ±;UâdÂ¥Â°%Ã³ÂlÃÃ±Ã=ÂhÃ½ÃmE[w"Ã©!MyâMyâ"c<2n[dÃ¿ÃÂ¢foÂ®Â°®Â°5Â¶anWAoÂÃÃaÃ©:YÂÃ±bx=Ã=ÃÃ4ÃBÂ©"L5â@`?ÃÃÂ©ââ¡Nk2ÃÃ»Ã¼Â°Ã¿Â·ÃÃ¸Â¸Â·=D` >ÃÂ¦9Ã¦ÃÂ³Ã¹oÂÂ¸Ã°ÃÂ±ÃÃ¤1Ã©ÃÂ¡ÃÂFÂ®r8 >[])}QJn>ÃuÃ¯Â¯j^Â¸[ÃÂ½1Â¸ÃÃÃ§5ÂÃ¨fÃ£IÃoÃÃ?~âÃâ¹|CUÃ¤ÃÃÂº;Ã¹DyÂ£c0a0 >`HÃ¸BÃ BÃ 0UÃ¿Ã°0U#0ÃnÂ¤8]BÃ1ÃÃÂÂ >]0U0Âlane(a)mcs.anl.gov0 > * HÃ· >|Ãr >Â¹vÃ§ÃW29zÂ¾MbÃÃÂ³Ã¾ÃÃÃ£saTÃârÃxÂ¶ >Â±<Ã°<]@ÃgzÃ±Ã¶#Â¬Ã»ÃºÂÃÃâpxÃÃÂ¯f^b"ÃâcÃÂcX>Â¡ÃD"kPÃÂÃ²Ã«SÃÂÂ?ÃºÂ¾=Ã¦#QÂ¼ÃâºÃ¦Ã³hâºÅ½Ã©[Â½Â¯Â´Ã¡0{Â¡i >ÃµÃ¢ÃÃÃ³Â¨Â¾Ã<Ã¢ Â<Ã¼W0ÆW0ÆPdÃ¦-Â±Ã-ÃÃ¢ >âZÂ}ÃÃ*%D6Â¸=iSpJ|Âµ0rÃi'LKÃuOÃ/l ÃcÃÂÂÆFÃ*ÃÂ«ÃÃ`c >Ã¤Ã(Â¯Â¯Ã¢`âGÂ®{Â©Ã¦ÂÂÃ>ÃÂ¾_ÃÃ·4Â¯ÃÃ1Ã·Ã¸ >Â¦Â¢=Ã¿9ÃJÃ¦Ã°Ã©Â¸Â¾Ã§0Â¦0 Ã0 > * HÃ· >0i10 â&âÃ²,dorg10 â&°âÃ²,dDOEGrids1 0UCertificate >Authorities10U >DOEGrids CA 10 >051111152456Z >061111152456Z0^10 â&âÃ²,dorg10 â&âÃ²,ddoegrids10 >UPeople10UPeter G Lane 3642430"0 > * HÃ· >0Â»ÃâÃ¤ÃÅÃ¤ÃÅÃ<Â¹ÃM >â¹Ã3Â¶Ã©=vU5Ã¢HÃÃ±zÂ®w7Â¼AhÃÃCÃ±;UâdÂ¥Â°%Ã³ÂlÃÃ±Ã=ÂhÃ½ÃmE[w"Ã©!MyâMyâ"c<2n[dÃ¿ÃÂ¢foÂ®Â°®Â°5Â¶anWAoÂÃÃaÃ©:YÂÃ±bx=Ã=ÃÃ4ÃBÂ©"L5â@`?ÃÃÂ©ââ¡Nk2ÃÃ»Ã¼Â°Ã¿Â·ÃÃ¸Â¸Â·=D` >ÃÂ¦9Ã¦ÃÂ³Ã¹oÂÂ¸Ã°ÃÂ±ÃÃ¤1Ã©ÃÂ¡ÃÂFÂ®r8 >[])}QJn>ÃuÃ¯Â¯j^Â¸[ÃÂ½1Â¸ÃÃÃ§5ÂÃ¨fÃ£IÃoÃÃ?~âÃâ¹|CUÃ¤ÃÃÂº;Ã¹DyÂ£c0a0 >`HÃ¸BÃ BÃ 0UÃ¿Ã°0U#0ÃnÂ¤8]BÃ1ÃÃÂÂ >]0U0Âlane(a)mcs.anl.gov0 > * HÃ· >|Ãr >Â¹vÃ§ÃW29zÂ¾MbÃÃÂ³Ã¾ÃÃÃ£saTÃârÃxÂ¶ >Â±<Ã°<]@ÃgzÃ±Ã¶#Â¬Ã»ÃºÂÃÃâpxÃÃÂ¯f^b"ÃâcÃÂcX>Â¡ÃD"kPÃÂÃ²Ã«SÃÂÂ?ÃºÂ¾=Ã¦#QÂ¼ÃâºÃ¦Ã³hâºÅ½Ã©[Â½Â¯Â´Ã¡0{Â¡i >ÃµÃ¢ÃÃÃ³Â¨Â¾Ã<Ã¢ Â<Ã¼W0ÆW0ÆPdÃ¦-Â±Ã-ÃÃ¢ >âZÂ}ÃÃ*%D6Â¸=iSpJ|Âµ0rÃi'LKÃuOÃ/l ÃcÃÂÂÆFÃ*ÃÂ«ÃÃ`c >Ã¤Ã(Â¯Â¯Ã¢`âGÂ®{Â©Ã¦ÂÂÃ>ÃÂ¾_ÃÃ·4Â¯ÃÃ1Ã·Ã¸ >Â¦Â¢=Ã¿9ÃJÃ¦Ã°Ã©Â¸Â¾Ã§0Ã¸0Ã 0 > * HÃ· >0u10 â&âÃ²,dnet10 â&°âÃ²,dES10UESnet1 0UCertificate >Authorities10UESnet Root CA 10 >021205080000Z >080110080000Z0i10 â&âÃ²,dorg10 â&âÃ²,dDOEGrids1 >0UCertificate Authorities10U >DOEGrids CA 10"0 > * HÃ· >0Â´ÃµÃ#aÂ£Ã>fÂµÂ;fÂµÂ¸ÂoÂ²Ã-jmrÂ¢ÃÂqÃ·Â¼+¼+.ÃÃcÃ¢,-Ã¿Y"Ãd >n1ÃÃ.kÃÃÃÃÂºdÃÂÃÂ´Ã«`Ãâ >IÃwÃÃ¡QâHWKTo@lÃÂ²yÃ¾ÃºqÂ¥BÃ~Â!t.Â7âÂ«8Ã´Ã5Ã¶^Ã6ZÃÃ\Ã¶Â·<Â5y9%Ã¾gÃ¬Â²KÃ!kÂ´ÃÃÃ_Ãº}!ÃÂ£ÃÂ£ÃÃ§|%ÂâwÃÃÆÃ¸ÂcCÂ¸vâQ[7ÃrÃoÃÂ³ÂµQÃ½lW7Â¾âÂ¾â°ÃÃlpk]-ÆÃ°ÃÃ¯âÃ¯cNÃÂªÃ¦Ã-tÃ¶Â«ÃÂ°ÃZÂ®ÆÃoÂ«<Â¦Â¤@ÂºJ{MÃ¸]Ã{ÃªROÃÃQZ)Ã¹cwÂ¯?KÂ£Â0Ââº0 >`HÃ¸BâBâ¡0UÃ¿Ã0UÃnÂ¤8]BÃ1ÃÃÂ >]0U#0Â¼]MH/Ã¸5âYÂ«\K>ÃÂ²Â²:Ãª0UÃ¿0Ã¿0%U0ÂDOEGrids-CA-1@doegrids.org0 > * HÃ· >*;b>Â3p{)5V#Æ+Â±Â¶(=vÃââ53Â¡Â¿(B7Ã¢ >xQÂ{ÃÂ¤Â´`-#âgÃKÃ¸j1q.Ã£Ã«8ÃÃÂ¶ÃÃ°Ra5ÃjÂ½BFBFÅ¡Â¹ÃÂÃ£Ã]=ÃÂ£3NQÃ«ji_gkÃEÂ´Â´ÂªxÃ½Ã^ÃÂ¸Â¿Â´Ã¾BkÃªÃÃÂ¹Ã±Ã®Â¥@ÃwÃ¨Â¨(vÂ¶cÂ¶âJÃHÃdjÂÃ1rIÂ¥Ã¿Â¿Â£Â°°Ã´ÃÂ¥Â½ÃÃ >u<iÃ»Â²@x1Ã®ÃÃÂ¼Â¯;DÃâÃª >Â©ZÂµk;Â>Ãz[Â½TÃÃ¯<xGÂ¸¸-*Ã#Ã)eSÃÂ½Âº >Â·Â±â¢Ã»Ã¾ÃªÃ(Ã´Ã¼ÂYyÂÂ§@Ã©ÃGfÂ¢Ã¥Ã¿.#AÂ»1N0J0o0i10 >â&âÃ²,dorg10 â&âÃ²,dDOEGrids1 0UCertificate Authorities10U >DOEGrids CA 1Ã0 + Â´0 *HÃ·â Ã· > 1 *HÃ· Ã· >0 *Hâ Ã· > 1 >060902205636Z0# *HÃ· > > 1<ÂÃºÃNÃ¾R[9+Â£Ã¬â$2Â³S0R *HÃ· > > 1E0C0 *HÃ· > > 0*HÃ· > > 0 >*HÃ· > > @0+0 >*HÃ· > > (0~ +71q0o0i10 â&âÃÃ²,dorg10 â&ââÃ²,dDOEGrids1 > 0UCertificate Authorities10U >DOEGrids CA 1Ã0Â*HÃ· >br> 1q o0i10 â&âÃ²,dorg10 â&âÃ²,dDOEGrids1 >0UCertificate Authorities10U >DOEGrids CA 1Ã0 > * HÃ· >>ÃÃSmÂ°dÃ²;Â±ÃÃ¾ÃÃ¾--âÃ|+ÂÃÃfÃ¯{qFÃ©,Â±Â±ÃzÂ¾ >Â»UÃÂ®JÃÂ¢ÃLÃHÃ¶Ã¡ >Ã´DÃº+WÃÆÂ±Â¹ÃÂ¹Ã¶VÂ¬ÂµÃ³âÃ¯Ã½2ÃÃÂ´5Ã²Â4Â§¡:Â¡Â²âÂ¸>bUVq >Ã½ÂÂ¼Â®Â©ZÃ¸ÃÃ¨O|Ã¶Â«0Âââ¹ >:cÃ©AÂ·ÃÃº%3Ã¤j1ÂâÃGÃq&ÂºÃc >[ZÃÃ7Â§.FZY#ÃÃÂ¸âX^Â¤lNxÃ¨SÃ¢WÃÃ >ÃªqÃÃÃ¤ÃÃ§Ã*â¢aÃâÃªÃ®/n3[m-SÃ1pâ1pâ¡7-Ã¥Â¢:<Ã¼ÃqÂµÃ9ÃÅÅ¾ >xÂÂFÃ¹<ÃÃ¯Ã¢;^Â¿Ât|G.Â¦ÃÆÃ¿|0_6 >-- > ogsa-hpcp-wg mailing list > ogsa-hpcp-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg > >_______________________________________________________________ >Ian Foster -- Weblog: http://ianfoster.typepad.com >Computation Institute: www.ci.uchicago.edu & www.ci.anl.gov >Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 >Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 >Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org > > >-- > ogsa-bes-wg mailing list > ogsa-bes-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/ogsa-bes-wg _______________________________________________________________ Ian Foster -- Weblog: http://ianfoster.typepad.com Computation Institute: www.ci.uchicago.edu & www.ci.anl.gov Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org

2 3

[wg-all] Mailing List Changes
by Andre Merzky 03 Sep '06

03 Sep '06

Sorry for duplicates ------------------------------------------------------------ As of yesterday, all GGF/OGF mailing lists are migrated to the ogf domain. They are now managed by mailman, the web interface is available at http://www.ogf.org/mailman/listinfo With that migration, all list can be now reached via <list>@ogf.org The old @ggf.org addresses will be available for some time, but are bound to disappear eventually - please start using the ogf addresses! A number of lists have changed their names: ggf-it --> ogf-it ggf-office --> ogf-office ggf-proc-wg --> ogf-proc-wg ggf-sponsors --> ogf-sponsors ggf-tutorials --> ogf-tutorials ggf-compute --> ogf-compute ggflistowners --> ogflistowners ggfstudentmembers --> ogfstudentmembers Postings to the old list names get forwarded to the new ones. With the migration we have also been able to fix the archives - you may have noticed that list archiving stopped sometime in mid June. Well, now its working again, and all mails from June to now have been added to the archive. The list archives can be found at: http://www.ogf.org/archives/<list> If you are an list administrator, and would like to receive the list admin password, please contact postmaster(a)ogf.org. In general, however, we tried to map the old majordomo settings to the mailman settings, in terms of privacy etc, so no or little changes should be required from your side. The spam avoidance policy has been changed to some extent, and is somewhat stricter than before. Please let us know if you experience any trouble with that. On all questions in respect to mailing lists, or mails in general, please contact postmaster(a)ogf.org. Best regards, Andre. -- "So much time, so little to do..." -- Garfield -- wg-all mailing list wg-all(a)ogf.org http://www.ogf.org/mailman/listinfo/wg-all

1 0

Re: [jsdl-wg] Re: [ogsa-hpcp-wg] Minutes for OGSA HPC Profile telecon (Aug 18 2006)
by Donal K. Fellows 01 Sep '06

01 Sep '06

Karl Czajkowski wrote: > On Sep 01, Andreas Savva modulated: >>... The question I have if you change the argument type to a >>string is then why do you need multiple argument elements? > > The arguments to a POSIX command are a vector of strings. The strings > may have any character in them, be empty strings, etc. You cannot > trivially talk about encoding this vector in a string unless you > assume a bunch of "quoting" conventions. [...] I agree completely with this point. The arguments are to contain the strings as seen in the argv argument to main(), excluding whatever well known leading arguments that are there first (i.e. the name of the executable). > That said, Donal's point about string encoding is important to > remember. To do it right, the implementation needs to translate the > XML info set string (unicode I think, right?) to the locale in which > the program will run. This might not be possible, unless we can > assume that the implementation can select an appropriately locale for > the characters being used. This is probably going to end up as a requirement on the BES spec. The XML infoset is defined in terms of UNICODE abstract characters, so when mapping to running a real executable there needs to be some encoding employed. Most encodings cannot render all UNICODE characters. Hence, if there are characters which cannot be encoded there probably SHOULD be a fault thrown. (I hesitate to say MUST.) I imagine that eventually all platforms will use UTF-8 as their native encoding - there are excellent reasons to do this shift - and that from then on, the encoding nasties will go away, but it's going to be a long time coming. Donal.

1 0

RE: [ogsa-bes-wg] Re: [ogsa-hpcp-wg] Minor BES issue
by Ian Foster 31 Aug '06

31 Aug '06

+1 At 06:59 PM 8/30/2006 -0700, Marvin Theimer wrote: >Hi; > > > >A question to address is what the interpretation is of having an operation >request receive only a subset of response elements in its reply. Consider >TerminateActivities: what are the failure semantics of having it succeed >(i.e. be successfully applied) to only a subset of activities? Presumably >the client wants back a vector of return information that describes >exactly what happened to each activity; i.e. they will want a vector that >contains either a success or a fault element for each activity that was >listed in the input vector rather than a vector containing just the >success elements or just the failure elements. For GetActivityStatus and >GetJSDLDocuments one might argue that its OK to get back information about >a subset of requested activities. But I would expect that clients would >still want to receive a failure element back explaining what happened for >each activity for which information could not be returned. > > > >Thus, it seems to me that in all cases clients will want to receive back a >vector response of the same length as the input vector. In particular, I >would advocate that they should expect one of the following responses back: > >· A fault response if the operation as a whole could not be handled >e.g. if the client is not authorized to make the request. > >· A response that consists of an info-set that contains a vector of >elements, where the number of elements equals the number of activities >specified in the input vector argument to the operation request. Each >element of the vector should be either a successelement or a fault >response element. Which input vector element the response element refers >to is unambiguously determined by the EPR returned in the response element >(as pointed out by Peter). An interesting question is whether the EPR >field is really needed since vector input arguments are only available for >operations on existing activities and one could request that the vector >order of the response message correspond to the vector order of the >request message. If we were to go down this path then we could simplify >the schema of the response messages. > > > >If BES were to take the approach outlined above then the HPC Profile >specification would contain a restriction that simply says that HPC >Profile-compliant services MUST support input vectors of length 1 and MAY >support vector lengths greater than 1 or MAY return an overall fault >response of not-implemented for vector lengths greater than 1. > > > >Thoughts? > > > >Marvin. > > > >-----Original Message----- >From: owner-ogsa-bes-wg(a)ggf.org [mailto:owner-ogsa-bes-wg@ggf.org] On >Behalf Of Peter G. Lane >Sent: Wednesday, August 30, 2006 8:27 AM >To: Donal K. Fellows >Cc: ogsa-bes-wg(a)ggf.org; ogsa-hpcp-wg(a)ggf.org >Subject: [ogsa-bes-wg] Re: [ogsa-hpcp-wg] Minor BES issue > > > >Donal K. Fellows wrote: > > > An issue came up recently during discussions in the HPC Profile WG, and > > > that was that the BES spec should require that the lengths of the input > > > vectors and output vectors in the operations GetActivitiesStatus, > > > TerminateActivities and GetJSDLDocuments should/must be the same length > > > (assuming no faults, naturally). Otherwise the responses might be a > > > subset of the expected ones. Maybe there are some other restrictions > > > that ought to be imposed (same order, referring to the same things thatt > > > the input referred to, etc.) but it was the length issue that came up > > > (since that's the aspect that's going to be profiled). We agreed that > > > this sort of restriction belongs in the base BES spec though; it's too > > > fundamental to belong in the Profile. > > > >The schema types for the output vector elements have EPR fields that >associate each element with an > >input vector element. So it doesn't really matter if the response is a >subset of the expected set or > >is out of order. I'm assuming that this is the point of including the EPR >fields. Is there a more > >fundamental reason for pushing for such a restriction? I don't have a >strong opinion either way. I'm > >just curious about how this is interpreted as "bad". > > > >Peter > > > > > > > > Donal. > > > > > _______________________________________________________________ Ian Foster -- Weblog: http://ianfoster.typepad.com Computation Institute: www.ci.uchicago.edu & www.ci.anl.gov Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org

1 0

Minor BES issue
by Donal K. Fellows 31 Aug '06

31 Aug '06

An issue came up recently during discussions in the HPC Profile WG, and that was that the BES spec should require that the lengths of the input vectors and output vectors in the operations GetActivitiesStatus, TerminateActivities and GetJSDLDocuments should/must be the same length (assuming no faults, naturally). Otherwise the responses might be a subset of the expected ones. Maybe there are some other restrictions that ought to be imposed (same order, referring to the same things thatt the input referred to, etc.) but it was the length issue that came up (since that's the aspect that's going to be profiled). We agreed that this sort of restriction belongs in the base BES spec though; it's too fundamental to belong in the Profile. Donal.

3 2