- ogsa-wg - lists.ogf.org

RE: [ogsa-wg] Thoughts on extensions mechanisms for the HPC profile work
by Dave Berry 04 May '06

04 May '06

Hi Marvin, It seems strange to me to limit yourself to a list of identifiers as a means of interacting with large numbers of jobs. Wouldn't it be more flexible to allow more complex expressions, such as "all jobs submitted by Marvin that use more than 4 processors and are currently running" (or whatever). You could build an appropriate information model, map it to a data model and provide a corresponding query language that clients could use to request the information they need. I agree that this is a service-oriented approach rather than a resource-oriented approach. However, having set up a particular query, you might want to repeatedly interact with the current state of that query. So it might make sense to register the query with the service and return an EPR that can be used to get the current set of results. I don't see much point in passing back an abstract name (e.g. a UUID) on its own. Without a reference to a resolution mechanism, clients won't be able to make much use of it. This is why URL's and URI's have been so successful; they include enough information for any client to know which mechanism to use to resolve them. This seems to be one advantage of the WS-Name proposal; it includes an abstract name with a reference to a resolution mechanism. Is it still the case that BES containers are allowed (or even encouraged) to return WS-Names? Would it be useful to have a means for composing WS-Name EPRs that use the same resolution mechanism in order to make a single WS-Name that can be used to query all of them? Dave. -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Marvin Theimer Sent: 29 April 2006 03:06 To: ogsa-wg(a)ggf.org Subject: [ogsa-wg] Thoughts on extensions mechanisms for the HPC profile work * Support for array operations and other forms of batching. * When 1000's of jobs are involved the efficiency gains of employing array operations for things like queries or abort requests are too significant to ignore. Hence a model in which every job must be interacted with on a strictly individual basis via an EPR is arguably unacceptable. * One approach would be to simply add array operations alongside the corresponding individual operations, so that one can selectively interact with jobs (as well as things like data files) in either an "object-oriented" fashion or in "bulk-array" fashion. One could observe that the array operations enable the corresponding individual operations as a trivial special case, but this would arguably violate the principle of defining a minimalist base case and then employing only extensions (rather than replacements). * Array operations are an example or a service-oriented rather than a resource-oriented form of interaction: clients send a single request to a job scheduler (service) that refers to an array of many resources, such as jobs. This raises the question of whether things like jobs should be referred to via EPRs or via unique "abstract" names that are independent of any given service's contact address. At a high level, the choice is unimportant since the client submitting an array operation request is simply using either one as a unique (and opaque) identifier for the relevant resource. On a pragmatic level one might argue that abstract names are easier and more efficient to deal with than EPRs since the receiving scheduler will need to parse EPRs to extract what is essentially the abstract name for each resource. (Using arrays of abstract names rather than arrays of EPRs is also more efficient from a size point-of-view.) * If abstract names are used in array operations then it will necessary that individual operations return the abstract name and not just an EPR for a given resource, such as a job. If this approach is chosen then this implies that the base case design and implementation must return abstract names and not just EPRs for things like jobs.

3 3

Extensible state model for jobs
by Christopher Smith 03 May '06

03 May '06

Hi all, As Marvin mentioned in his email on extensibility and composition of protocols, I'd like to present this short document describing, in more detail, a model for extending the state model of jobs from a "base profile". The document is based on some discussions that Marvin and I have been having about scheduler interoperability, and is very close to the model that has been proposed within the SAGA working group. Please review Marvin's email about extensibility to get a feel for the "context" of the model. It is my intention to show how the ESI and BES state models can be represented using this approach. I'll try to get that done before Tokyo, but might just need to present some slides at GGF17, assuming I'm given a few minutes to do so. This is very much a work in progress, so I'm looking forward to feedback.... A note for the SAGA group .... I'd still like to see "pending" in the base job state diagram ... don't know why it disappeared. ;-) -- Chris

2 3

Re: ws-naming telcon tomorrow (Wednesday)? Re: [ogsa-naming-wg] RE: Minutes and next meeting
by Frank Siebenlist 03 May '06

03 May '06

I am on the naming mailing list, but I did not see any confirmation whether or not this telcon was going to happen and what the associated telcon info would be... Thanks, Frank. Andrew Grimshaw wrote: > Yes, It was in the last email. Which of course you did not get because you > are not on the email list. > > The dial in is: > > Toll Free: 866-231-9615 > > Long Distance: 713-576-2028 > > Participant Code: 255921 > > > There will be glance. > > > >> -----Original Message----- >> From: Frank Siebenlist [mailto:franks@mcs.anl.gov] >> Sent: Tuesday, May 02, 2006 7:02 PM >> To: Andrew Grimshaw >> Cc: ogsa-naming-wg(a)ggf.org; ogsa-wg(a)ggf.org >> Subject: ws-naming telcon tomorrow (Wednesday)? Re: [ogsa-naming-wg] RE: >> Minutes and next meeting >> >> Hi Andrew, >> >> Will we have another telcon tomorrow at 11am EDT? >> >> If so, is there any telcon# >> >> Thanks, Frank. >> >> >> Frank Siebenlist wrote: >> >>> I can make this ws-naming Wed 11am EDT telcon. >>> >>> -Frank. >>> >>> Andrew Grimshaw wrote: >>> >>> >>>> All, >>>> >>>> I committed to 11 AM Tuesday without checking my calendar. I have a >>>> >> PhD >> >>>> proposal to attend: >>>> >>>> "Federated Trust Management in Service Oriented Architectures". (Not >>>> >> one of >> >>>> my students.) >>>> >>>> >>>> >>>> I would like to propose that we "meet" Wednesday at the same time. >>>> >> Please >> >>>> respond if you cannot make that time - and were planning on attending. >>>> >>>> >>>> >>>> >>>> >>>> A >>>> >>>> >>>> >>>> _____ >>>> >>>> From: Andrew Grimshaw [mailto:grimshaw@cs.virginia.edu] >>>> Sent: Friday, April 28, 2006 1:03 PM >>>> To: 'ogsa-naming-wg(a)ggf.org' >>>> Subject: Minutes and next meeting >>>> >>>> >>>> >>>> All, >>>> >>>> Attached are the minutes from today's teleconference. Minutes are >>>> >> also on >> >>>> gridforge. >>>> >>>> The next teleconference is Tuesday, May 2, at 11AM Eastern. >>>> >>>> The dial in is: >>>> >>>> Toll Free: 866-231-9615 >>>> >>>> Long Distance: 713-576-2028 >>>> >>>> Participant Code: 255921 >>>> >>>> >>>> >>>> Glance will be provided at ogsa.glance.net >>>> >>>> >>>> >>>> Agenda: >>>> >>>> >>>> >>>> Agenda bashing >>>> >>>> Approve minutes >>>> >>>> Continue discussion of WS-Naming modifications to make consistent >>>> >> with draft >> >>>> requirements document. >>>> >>>> Go through tracker >>>> >>>> >>>> >>>> A >>>> >>>> >>>> >>>> Andrew Grimshaw >>>> >>>> Professor of Computer Science >>>> >>>> University of Virginia >>>> >>>> 434-982-2204 >>>> >>>> grimshaw(a)cs.virginia.edu >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> -- >> Frank Siebenlist franks(a)mcs.anl.gov >> The Globus Alliance - Argonne National Laboratory >> > > -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

Re: [ogsa-naming-wg] RE: Minutes and next meeting
by Frank Siebenlist 02 May '06

02 May '06

I can make this ws-naming Wed 11am EDT telcon. -Frank. Andrew Grimshaw wrote: > All, > > I committed to 11 AM Tuesday without checking my calendar. I have a PhD > proposal to attend: > > "Federated Trust Management in Service Oriented Architectures". (Not one of > my students.) > > > > I would like to propose that we "meet" Wednesday at the same time. Please > respond if you cannot make that time - and were planning on attending. > > > > > > A > > > > _____ > > From: Andrew Grimshaw [mailto:grimshaw@cs.virginia.edu] > Sent: Friday, April 28, 2006 1:03 PM > To: 'ogsa-naming-wg(a)ggf.org' > Subject: Minutes and next meeting > > > > All, > > Attached are the minutes from today's teleconference. Minutes are also on > gridforge. > > The next teleconference is Tuesday, May 2, at 11AM Eastern. > > The dial in is: > > Toll Free: 866-231-9615 > > Long Distance: 713-576-2028 > > Participant Code: 255921 > > > > Glance will be provided at ogsa.glance.net > > > > Agenda: > > > > Agenda bashing > > Approve minutes > > Continue discussion of WS-Naming modifications to make consistent with draft > requirements document. > > Go through tracker > > > > A > > > > Andrew Grimshaw > > Professor of Computer Science > > University of Virginia > > 434-982-2204 > > grimshaw(a)cs.virginia.edu > > > > > -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 1

please add me to the ws-naming gridforge project members...
by Frank Siebenlist 02 May '06

02 May '06

Not sure what the "procedure" is to get this accomplished, but i've tried clicking on the "Request Project Membership", emailed admins, send email to the ws-naming list... it's almost as I'm not welcome to join ;-) -Frank. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

Teleconference minutes - 27 April 2006
by Andreas Savva 01 May '06

01 May '06

Attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060427/en/1 See you at GGF17. -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 27 April 2006 =================================== * Participants Jay Unger (IBM) Jem Treadwell (HP) Ellen Stokes (IBM) Dave Snelling (Fujitsu) Andreas Savva (Fujitsu) Joel Replogle (GGF) Steven Newhouse (OMII) Mark Morgan (UVa) Fred Maciel (Hitachi) Hiro Kishimoto (Fujitsu) Minutes: Andreas Savva * Summary of new actions ACTION: Ellen will do an example of a cluster (e.g., the glue cluster model) and the 'red' to 'blue' mapping for it ACTION: Hiro/Dave S/Jay/Ellen/... to talk offline and make a proposal for a summer meeting location and time, possibly in mid-July. * April 24 minutes (draft 2) approved with no changes * Webcast recap Webcast went well and a recording will be posted in due course. There were some dial-in issues and these may explain why there was no voice Q&A. A number of questions were submitted through the online system. A good percentage of registered people turned up and Jem's impression is that most were new to OGSA. Jay mentioned that sometimes people register just so that they can get an update email later for the recording. One idea is not to state in advance that a recording will be available later. Also people may not eventually turn up due to the inconvenient time slot. Doing webcasts in two parts may help against the inconvenient time slot problem. For example, do just the explanation and post the recording. And then arrange for multiple Q&A sessions at different times convenient to different time zones. The group produced a good slide deck and it is expected that it can be used for other occasions. For example, Hiro is planning his keynote off this deck. Mark Linesch also attended. Thanks to all who took part and especially to Jem for pulling everything together despite the tight schedule. * Action review [Only updated actions shown here.] - Steven Newhouse to ask Jennifer Schopf on the status of the GIN modeling document. There is no such document; delete action. (Done) - Ellen will do a revised visio diagram that has only the relevant BES attributes and JSDL attributes (base it off the info_model_for_BES/BES Container class) It is today's agenda. File (pdf) has been uploaded. - Hiro asked Ellen to also upload the Visio file to gridforge. - Andreas will sent information to Ellen on how to attach a file (e.g., visio) to a pdf file to simplify uploading to gridforge. (Done) - Andreas: to finalize OGSA WSRF BP 1.0 doc and make a final call - An updated draft is available and should be made public within a few days. * GGF17 session review ** Keynote - Hiro is planning to base his keynote on the webcast material after removing basic stuff and merging some slides into transitions. ** Information model - Discuss capabilities and requirements and their relation, including position papers. ** EMS session - Andreas has confirmed that NAREGI (beta) is not using WS-Agreement. - Steven N will produce a new version of the Scenarios document by GGF17. ** Session scheduling - Steven Newhouse has conflicts with both OGSA sessions. The group discussed re-scheduling options, including swapping times with other groups. - One session (EMS) was moved to Wednesday at 5:45 and the other (Information Model) to Friday at 1:45. There is now a conflict with RSS-WG and Joel will offer them one of the vacated OGSA slots on Thursday. ** OGSA F2F update Discussed options for OGSA F2F during the summer. Previously the group had agreed on two meetings: end of June and end of August. In this call there was no consensus for two meetings during the summer. Instead it was agreed to have a single meeting mid-July. ACTION: Hiro/Dave S/Jay/Ellen/... to talk offline and make a proposal for a summer meeting location and time, possibly in mid-July. * Information model discussion Using the material sent out by Ellen. https://forge.gridforum.org/docman2/ViewProperties.php?group_id=42&category… ** Slide 2 The abstract model (in blue) is intended to be much simpler than the instance model (red). It is a list of capabilities of the container, probably described as <name, value> pairs. For example: <name = operatingsystem, value = redhat> and so on There was agremeent that it is desirable for resource capabilities (blue) and activity requirements (green) to have the same language (symmetrical rendering) and that the simple model (blue) should be generated and updated (automatically by algorithms) from the detailed model (red). The main unresolved difference is whether extensibility should be done using xml extensibility (as envisaged by JSDL) or by defining some xml (typeless) element that can express 'something' as a capability. One example to highlight this difference is <OperatingSystem> RedHat </OperatingSystem> versus <capability name=OperatingSystem value=RedHat> It was agreed to table the rendering issue for now. ** Slide 3 - The concrete CIM 'stuff' gets mapped into the 'aggregated' BES abstract stuff - Note the duality of jsdl 'execution requirements': as both job requirements and container capabilities. ** Slide 4 ACTION: Ellen will do an example of a cluster (e.g., the glue cluster model) and the 'red' to 'blue' mapping for it

1 0

FINAL CALL: OGSA WSRF BP 1.0 (draft 46)
by Andreas Savva 01 May '06

01 May '06

This is a final call for re-submitting a revised version of the OGSA WSRF BP 1.0 to the GGF Editor. Please review draft 46 (changes accepted) or draft 45 (change-tracked version) and send your comments to the list until the end of business Friday, May 5. Background: You may recall that the WSRF BP 1.0 finished its public comment last December. A revised version was ready in January but it was agreed to wait for the publication of OASIS Standard versions of the WSRF specifications. This version uses the OASIS Standard WSRF specifications; and was also updated to make the other referenced specifications consistent (e.g., use the same version of WS-Addressing). Draft 46: https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-wsrf-b… or http://tinyurl.com/lxfkz Draft 45: https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-wsrf-b… or http://tinyurl.com/kf7r5 Thanks to all who reviewed versions leading up to this one and especially to Vivian Li for checking the referenced specifications. -- Andreas Savva Fujitsu Laboratories Ltd

1 0

No call on May 1, 4, and 8
by Hiro Kishimoto 29 Apr '06

29 Apr '06

Hi all, Since the week of May 1st is Japanese holidays (Golden Week), OGSA-WG will have no calls. Also many of you are going to travel on May 8th, we don't have a call either. Have a great weekend! Thanks, -- Hiro Kishimoto

1 0

[Fwd: [ogsa-naming-wg] Minutes and next meeting]
by Frank Siebenlist 28 Apr '06

28 Apr '06

FYI - Frank. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

More comments: HPC Use Cases -- Base Case and Common Cases
by Balle, Susanne 28 Apr '06

28 Apr '06

Marvin, Enclosed find the remaining of my comments: Page 5. (top paragraph) I think I know what you mean by "with the ambiguity of distinguishing between scheduler crashes and network partitions ". "scheduler crashes" is obvious. I am assuming that by "network partitions" you are inferring that various sub-networks are going to have different response time which will have an effect on the time it takes to deliver a call-back message. Reading further along in the same paragraph I am now not sure I know what you mean by "network partitions". Page 5. Section 3.3 The topic of this section is clear (described in the first line of the paragraph) but of the section is a little confusing. "possibility that a client cannot directly tell whether its job submission request has been successful ..." --> Do we expect the client to re-submit the job if the submission failed or do we expect users to inspect that their job has in fact been submitted and resubmit if needed? I am wondering if we assume the later if that wouldn't result in users re-launching their jobs several time if they do not see their job listed in some state when pulling the job scheduler for the state of their job? I guess I do not understand why so much emphasis is put on the "At-Most-Once" or "Exactly-Once". Can't the client poll the Job scheduler and ask the JS for a list of jobs queued, running, terminated, failed, etc.? It might be useful for the client to be able to submit jobs with a special keyword like JOB_SUBMITTED_BY since that would reduce the list it gets back. It would be nice if the value for the keyword was a unique identifier but doesn't have to be. Most schedulers allows you to name or associate a group to programs so that feature could be used as special keyword. Page 6. Section 3.4 General question: Are you taking into account that user applications will require different software? 1. For example if my executable is compiled for Linux, Intel platform then I would like to run it on a Linux,Intel system and not a Linux,AMD system. 2. Are you assuming that the program will be compiled on the fly on the allocated system? or pre-compiled and then staged? I agree that staging the data is going to be an interesting topic. All this is probably out-of-band for the HPC JS Profile but should be considered somewhere. I am sure it is I just don't know where. I like the section on virtual machines and think that they will be used more and more in the future. Page 7. Extended Resource Features The second approach (arbitrary resource types ...) is the only one that make sense to me since that approach is extensible. I believe that Moab is implementing this approach as well. Page 8. Extended Client/System Administrator Operations Are you assuming that System Administrators will be able to perform sys admin operations on somebody else's system? I don't think that is right. You mention suspend-resume. Are you thinking of suspending a job running across several clusters that are in different organizations? Or just suspending a job on a single cluster/server? Again I am trying to figure out how this fit in with "One important aspect, is that the individual clusters should remain under the control of their local system administrator and/or of their local policies". I believe that suspend-resume is a JS operation or an operation to be performed by the local sys admin, NOT by remote sys admins. If we are now talking about a meta-scheduler then yes it makes sense. In the case of a meta-scheduler it might take over the individual JS and schedule jobs base on its own policies, on its job reservation system, etc. In this case I look at it as we have one deciding entity (the meta-scheduler) and several "slaves". Moab and Maui are the only meta-scheduler I an familiar with and they do take over the scheduling decisions/node allocations/etc and just submit jobs to the local job schedulers. This does of course assume that the local system administrators have agreed on a schedule when their cluster is shared within this greater infrastructure. This is a different approach than having jobs passed onto their local scheduler and run on their systems. This just seems to be a different approach from the one that is taken in this paper. I might be wrong. If I am please educate me. Page 9. Section 3.10 Don't forget UPC (Unified Parallel C: http://upc.nersc.gov/) This parallel programming paradigm is getting more and more interest from several communities. We'll need to provide support for UPC as well. Page 10. Section 3.13 A meta-scheduler approach that make sense to me is to allow developers to submit their job to their local cluster using their "favorite" scheduler commands and then have the meta-scheduler load-balance the work and forward the job to another system/cluster if needed. Moab from cluster resources support this approach even if the clusters have different JSs. They have a list of supported JS such as LSF, PBSpro, SLURM, etc. and they can "translate" one JS's commands into another within that supported set. Page 11. SLURM is missing. Let me know what you think, Regards Susanne --------------------------------------------------------------- Susanne M. Balle, Hewlett-Packard High Performance Computing R&D Organization 110 Spit Brook Road Nashua, NH 03062 Phone: 603-884-7732 Fax: 603-884-0630 Susanne.Balle(a)hp.com

2 1