August 2006 - ogsa-hpcp-wg

Proposed rephrasing of the restriction on BES vector operations in the HPC Profile
by Marvin Theimer 18 Sep '06

18 Sep '06

Hi; As you may recall from the discussions at the Tokyo GGF conference, it was agreed that the HPC Profile base case would be kept as simple as possible in order to make it as easy as possible to create a compliant BES service (and to forestall feature creep). Among other things, that meant that we agreed upon requiring the HPC Profile-compliant BES services would only be required to support BES vector operations of length 1. But of course we'd like to allow compliant BES services to support vectors of length greater than 1 if they so desire (which we expect to be the common case). Enclosed is a rewording of the paragraph in section 4 of the HPC Profile specification draft that restricts vector lengths of BES operations. I've rewritten it to clarify that vector lengths greater than 1 are allowed but may result in a fault. Please let me know if you would like additional rewording to occur. If I don't hear any rewording suggestions in the next few days then I'll go ahead and insert the rewording shown into the HPC Profile document. Reworded paragraph: The BES GetActivitiesStatus, TerminateActivities, and GetJSDLDocuments operations include a vector input parameter that specifies the set of activities that the operation should be applied to. A Compliant system MUST be prepared to support a vector length of 1. A Compliant system SHOULD support input vector lengths greater than 1 but MAY return a Not_Supported fault in response to input vector lengths greater than 1. Thanks, Marvin.

5 5

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-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

Friday (Sept 1) conf call will cover JSDL basic execution extension, interop plans
by Marvin Theimer 30 Aug '06

30 Aug '06

Hi; This Friday's HPC Profile call will be at the usual time and "place": * Friday, 9/1, at 10AM EDT (7AM PDT) * 1-866-500-6738 (from US & Canada) or 1-203-480-8000 * Passcode: 1157025 The tentative agenda is the following: * Cover the suggested changes to the JSDL basic execution extension specification. (We didn't have quorum at today's JSDL conf. call, so we are pushing discussion to the HPC Profile conf. call and will then be sending a "summary" email to the JSDL mailing list requesting comments.) * Discuss interop plans and compliance specifications. Marvin.

1 0

call for implementers of the OGSA HPC Profile
by Marty Humphrey 28 Aug '06

28 Aug '06

Folks, As chairs of the OGSA HPC Profile WG, Marvin Theimer and I think that we're getting sufficiently close to having a profile defined that we'd like to issue the call for implementers of the OGSA HPC Profile. While there is clearly some more work to be done on the current HPC Profile draft (and the BES spec), we believe that certain ambiguities in the current HPC Profile can only be identified and resolved when parties try to get their implementations to speak with each other. We seek implementers to (a) help solidify the profile through direct interoperability testing, and (b) help define the compliance suite. Therefore, we encourage people interested in prototyping an implementation to email me (Marty Humphrey). The current version of the HPC Profile spec can be found at: http://forge.ggf.org/sf/go/doc13736?nav=1 Thanks a bunch! Marty Marty Humphrey Assistant Professor Department of Computer Science University of Virginia

1 0

Minutes for OGSA HPC Profile telecon (Aug 25 2006)
by Marty Humphrey 26 Aug '06

26 Aug '06

OGSA HPC Profile Minutes - Fri Aug 25 2006 Participants: Marty Humphrey (University of Virginia) Marvin Theimer (MSFT) Glenn Wasson (University of Virginia) Michel Drescher (Fujitsu Europe) Minutes: Marty Humphrey * Summary of Actions: AI-HPCP-0825a: Everyone will re-read Donal's version of the HPC Profile Application in the JSDL section of Gridforge by Friday Sept 1 call. AI-HPCP-0825b: Check with BES doc and/or WG to determine the "final word" on issues of idempotency and subscriptions (and others). AI-HPCP-0825c: Marvin will suggest phrasing re: vectors to the email group for consensus. AI-HPCP-0825d: Marvin will mopdify HPC Profile doc to resolve Chris' comments, restrict to integer the total CPU count, total resource count and individual CPU count. AI-HPCP-0825e: Marty to send email to BES/JSDL/HPCP: "We are looking for prototype and interop participants." * Previous minutes: Approved * Review of Actions AI-HPCP-0818a: Donal Fellows to review HPC Profile Application. DONE. On Mon Aug-21, Donal Fellows uploaded a new version to the JSDL space in Gridforge. The main modification is a more comprehensive security section. Our group discussion in today's telecon on this subject resulted in AI-HPCP-0825a: AI-HPCP-0825a: "Everyone" will re-read it (in the JSDL section of Gridforge). On the Sept 1 call, we will determine (via vote) if we believe that it's ready for ratification via the JSDL group and the large OGF at large. In short, Michel suggested that we keep it in the HPCP gridforge section while it is being actively worked on and transition it to the JSDL section when it's ready for "normative radification". Because it's currently in the JSDL forge section, we will only "pull it back" to HPCP if, upon reading it, we decide (collectively) that it needs modifications (see AI-HPCP-0825a). 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" DONE. This is discussed in this telecon, below. AI-HPCP-0818c: Marvin Theimer will add first draft of section 4 to HPC Basic Profile that restricts BES operations to singletons DONE. This is discussed in this telecon, below. * Go over changes to HPC Profile that Marvin sent out ----------------------------------------------------- Marvin: Before giving an overview of the modifications, there's an issue/question to BES guys: what about idempotency and subscriptions (and perhaps other issues)? That is, this was either in a previous version of the BES space *OR* explicitly mentioned to be included in a future version (but it's not mentioned in the current BES spec). We understand that this will appear as an option in the BES spec, but this has implications on the HPC Profile (e.g., we might like to restrict this and/or claim that such considerations are out-of-scope). Marty: Yes, we knew this going in -- that JSDL is "easier" in that it's fixed in stone, while BES is a moving target. This makes profiling difficult. AI-HPCP-0825b: Check with BES doc and/or WG to determine the "final word" on this issue. Marvin gives an overview of his modifications, beginning with the proposed text in the Intro paragrph to Section 3 (consensus: working is fine). Marvin described Mods to Section 4: changed the intro, and vectors must be exactly length 1. The group discussed at depth the issue of the treatment of vectors Initially, the group wanted to insert something akin to Michel's proposed test in email 8/25 Glenn: isn't there potential confusion: the client sends a vector of size greater than 1... what exactly does the service do? Does the service have a choice which one to choose? Marvin: BES needs to deal with this case, although there are two different classes of faults. There is a BES fault - "error in inputs (the following inputs -- activity IDs -- were unknown)" and an HPC Profile fault ("the vector is too large") Glenn: suggests that the base profile should say 1 (and return a size of 1) and greater than 1 is a fault; extension: here's how it maps differing size inputs to differing size outputs Marvin: asks for clarification: extension to BES, right? this idea that "I don't return exactly what was specified" is a BES concept Glenn: yes Michel: saying that you'll return a vector of size 1 retricts composability; instead, return a vector of the same size Marvin: Good point -- it may handle things of size greater than one -- if so, then it must return a vector of the same size. But it may fault. It MUST handle a vector of size 1. If it handles a vector of size larger than one, then it would publish an attribute indicating so. Michel suggests wording that the client "SHOULD" try to use a vector of size 1 but the group consensus is (while the intent is good) that this is not the best wording because it could be interpreted to make clients ONLY work in terms of vectors of size 1 -- this is not the intent and might restrict clients. AI-HPCP-0825c: Marvin will suggest phrasing and send it to the email group for consensus. Marty to make this into a tracker. this concluded the discussion of vectors. Marty: What about total CPU count? "non-exact" clearly has value, but it just seems too complicated for interop, for compliance Marvin: In addition, not all schedulers implement a range, so let's make it exact. Marty: Section 3.2.5.8. What is "total resource count"? Michel: this is for "tiling" - e.g., 5x10processes. Marty: Let's make this exact as well. Group consensus is that this is reasonable. Marvin: some of these issues can arise and be resolved during implementations as well Marty: what about Chris' comments? Re: RAM... "total physical memory" is certainly easier. Michel: JSDL had long discussions... it comes down to requirements and capabilities. Marvin: this must be clarified in the HPC profile. in our JSDL section, make these appear as requirements. That is, the phrasing of the text in the JSDL section of the HPC Profile should clearly indicate that they're *requirements* (not capabilities). In the BES section of the HPC profile, make the text clearly reflect that these are capabilities (not requirements). Michel: Section 3 of HPCP is clear. Section 4 needs clarification: if BES exposes this via JSDL terms, then we need to clarify that these are capabilities, which are static values. Marvin: 3.2.5.6 and 3.2.5.7 need to have clarifications changed. Glenn: we need to restrict to integer in the total CPU count, total resource count and individual CPU count Group consensus on this AI-HPCP-0825d: Marvin will resolve Chris' comments by making clarifications that these are requirements. In addition, Marvin will change the document to restrict to integer the total CPU count, total resource count and individual CPU count * Discuss prototyping and interop opportunities and next-steps. --------------------------------------------------------------- The group agreed that the HPC Profile document is reasonably close to completion, so it was suggested that we start developing prototypes and perform interop testing to further disambiguate the document (and start developing a compliance suite) Michel: this document should get into public comments first, so we should wait before creating implementations Marvin: I propose something slightly different... I propose that we put up for public comment and in parallel do implementations... this is primarily due to time contraints. Marty: Public comment is good, of course, but can we do anything to ensure that the vendors are engaged/committed? Marvin: I will send it directly to Sun, Altair, Condor, Globus, ESI, etc.... "please please review this carefully and contribute..." Marty: if we get Marvin's changes in the BES (and "security section"), we will SUSPEND development of the HPCP docment AI-HPCP-0825e: Marty to send email to BES/JSDL/HPCP: "We are looking for prototype and interop participants. We will be start to discuss compliance suite. This will be the agenda for next week's call. first round of interop will be attempted BEFORE ggf18 (exactly what? we're not sure). Two phases: phase 1: quick, phase 2: for interop after GGF18. Discussion fo extensions can be accomodated RIGHT NOW in parallel to this -- to keep the momentum going. Meeting concluded. Next call: Friday Sep 1 2006 7am Pacific time.

1 0

Next telecon call is tomorrow (Fri.) at 7AM PDT
by Marvin Theimer 25 Aug '06

25 Aug '06

Hi; The next HPC Profile telecon call will occur at the standard time and date, namely Friday at 10AM EDT, 7AM PDT. Toll-free number (from US & Canada): 1-866-500-6738 (from US & Canada) Toll number for rest of world: 1-203-480-8000 Passcode: 1157025 Agenda: * Go over changes to HPC Profile documents that Marvin will be sending out in a little while. * Discuss prototyping and interop opportunities and next-steps. Marvin.

2 1

Re: [ogsa-hpcp-wg] Version 0.1 of HPC Basic Profile document
by Ian Foster 25 Aug '06

25 Aug '06

Marvin: Regarding: "The only restriction on the BES base case specification is that for the GetActivitiesStatus, TerminateActivities, and GetJSDLDocuments operations the length of the input vector of activities parameter MUST be exactly 1." Is there a need to indicate the error that should be returned if the length is different than 1? Ian. At 10:49 PM 8/24/2006 -0700, Marvin Theimer wrote: >Hi; > >Enclosed is the revised version of the HPC Basic Profile document. I've >added the paragraph to section 3 making it explicit that JSDL documents >MAY include additional elements that a compliant system may respond to >with a fault and I've filled in section 4 on BES. > >Marvin. _______________________________________________________________ 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 2

Version 0.1 of HPC Basic Profile document
by Marvin Theimer 25 Aug '06

25 Aug '06

Hi; Enclosed is the revised version of the HPC Basic Profile document. I've added the paragraph to section 3 making it explicit that JSDL documents MAY include additional elements that a compliant system may respond to with a fault and I've filled in section 4 on BES. Marvin.

1 0