- ogsa-wg - lists.ogf.org

Re: [ogsa-wg] More comments: HPC Use Cases -- Base Case and Common Cases
by Ian Foster 28 Apr '06

28 Apr '06

Susanne: I'd like to respond to your comments. I believe that the reference to "network partitions" refers to the fact that in a distributed environment, unlike a single machine environment, we cannot be sure that messages will be delivered: a network failure can result in any message being lost. Thus, a job submission may not receive a response, and in that case, we cannot know whether the job was submitted (i.e., the request got through, but the response was lost) or not (i.e., the request was lost). One convenient way of dealing with this problem is to allow users to associate a "unique job id" with a job request. A scheduler that receives a second or subsequent submission with the same jobid should simply return the response it provided to the first request received. It's true that a user can achieve a similar effect by searching for the submitted job in the scheduler queue. However, this approach is more complex to do, and also suffers from the problem that the job might have already completed and thus can't be found that way. In our recently circulated ESI specification, we proposed an optional "unique job id" field in JSDL as a way of addressing this requirement. This notion was discussed on a BES call, and people seemed sympathetic to the idea. Ian. At 12:20 PM 4/28/2006 -0400, Balle, Susanne wrote: >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 _______________________________________________________________ Ian Foster, Director, Computation Institute Argonne National Laboratory & University of Chicago 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. Web: www.ci.uchicago.edu. Globus Alliance: www.globus.org.

3 2

#new-4 add optional IRI/URI "matching-pattern-string" to meta-data section of an EPR Resolution Service's EPR
by Frank Siebenlist 28 Apr '06

28 Apr '06

Summary: #new-4 add optional IRI/URI "matching-pattern-string" to meta-data section of an EPR Resolution Service's EPR Tracker: Naming Comments by Frank Description: As we can have many different IRI/URI schema for resolvable end point identifiers with many different EPR Resolution Service implementations that only know how to deal with certain IRI/URI schema. In order for a client to know what resolution service instance to use for the EPI that it has, a matching-pattern can be associated with a resolution service instance that the client can use to match the EPI. Such a matching-pattern-string could be added the meta-data section of an EPR Resolution Service's EPR -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

#new-3 add optional "Unambiguous Web Service Endpoint Profile" and/or "Web Service Endpoint Address Identifier Profile" label to meta-data section of an EPR
by Frank Siebenlist 28 Apr '06

28 Apr '06

Summary: #new-3 add optional "Unambiguous Web Service Endpoint Profile" and/or "Web Service Endpoint Address Identifier Profile" label to meta-data section of an EPR Tracker: Naming Comments by Frank Description: To help the EPR consumer's processing logic, the minter or any intermediate with enough knowledge about the EPR usage can add a (optional) profile label to the EPR. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

Glance will be used as well
by Andrew Grimshaw 28 Apr '06

28 Apr '06

I will be hosting a glance session for the call this morning. Ogsa.glance.net Session key: 0428 Andrew Grimshaw Professor of Computer Science University of Virginia 434-982-2204 grimshaw(a)cs.virginia.edu

1 0

FW: [ogsa-naming-wg] Call in number for tomorrow morning
by Andrew Grimshaw 28 Apr '06

28 Apr '06

All, It has been pointed out to me that I forgot to cross-post. Sorry for the late info on the call #. A _____ From: owner-ogsa-naming-wg(a)ggf.org [mailto:owner-ogsa-naming-wg@ggf.org] On Behalf Of Andrew Grimshaw Sent: Thursday, April 27, 2006 3:46 PM To: ogsa-naming-wg(a)ggf.org Subject: [ogsa-naming-wg] Call in number for tomorrow morning All the dial in information is 1-877-422-0033 Passcode: 348140. I've never used this number - so watch for email in the first few minutes if you cannot get in and I need to send out instructions. Recall the agenda is: Proposed Agenda: Max time Subject 5 minutes Agenda bashing 30 minutes Discuss draft requirements document including vis a vis existing draft WS-Name document 30 minutes Discuss approval of DRAFT WS-Names document to send to GFSG for GFSG approval. Note we will prepare a version that does not include the language that overlaps 5.3. 25 minutes Attempt to come to closure on working group consensus regarding WS-Directory, RNS, or failing that, at least what the issues are. Andrew Grimshaw Professor of Computer Science University of Virginia 434-982-2204 grimshaw(a)cs.virginia.edu

1 0

#new-2 resolution should optionally return referral-EPR, RR or IRI/URI
by Frank Siebenlist 28 Apr '06

28 Apr '06

Summary: #new-2 resolution should optionally return referral-EPR, RR or IRI/URI Tracker: Naming Comments by Frank Description: In order to support global resolution names and services, the resolution service and renewableReference should optionally be able to return an EPR to another resolution service or other RenewableReference or alternative URI. This is the referral functionality that makes DNS/LSID/Handle do their global resolution. The client can distinguish the EPRs by porttype/interface, and when a new resolution service EPR is returned instead of an expected application-svc-EPR, then the resolution of the URI should be attempted with the new resolution svc instance. Similar for RR and URI. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

#new-1 zero, one or more "abstract-names"
by Frank Siebenlist 28 Apr '06

28 Apr '06

Summary: #new-1 zero, one or more "abstract-names" Tracker: Naming Comments by Frank Description: There is no reason to assume that there will be only one very special "abstract-name", and thus the spec should cater for 0, 1, or many. Same is true for RenewableReferences and resolution service EPRs. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

#1746 epr-hint removal
by Frank Siebenlist 28 Apr '06

28 Apr '06

Summary: #1746 epr-hint removal Tracker: Naming Comments by Frank Description: remove the optional parameter "epr-hint" for the renewable reference because its use and associated semantics is very confusing and doesn't add functionality. If the resolver can make use of additional information in the original EPR, then the renewable reference minter can add that to the RR-EPR's Address and/or ReferenceParameters. In other words, there is no point in putting the burden on the client to "guess" whether it makes sense to communicate the original EPR or not, because the minter can do it much better. Furthermore, the burden is still on the client to verify whether the reply is a new EPR or not. Andrew Grimshaw (2006-03-16 13:47:33) I'd rather not remove it. In our experience with an earlier re-resolution scheme it is very useful to know which EPR the client has already tried ... because if they just tried an EPR and it did not work, why give them exactly the same one back? Instead, you want to give them another, "fresher" one if one is available. For example, suppose my resolution service is really a binding cache, binding abstratnames to EPR's - or if i am not using abstract names to id services, whatever i am using in the EPR to id services. Clients use the cache service to get bindings. If they don't pass in the binding they used - they may get the same one back. Frank: Please read my comment again... the epr-minter of the renewable reference EPR can embed information about the EPR in which it was embedded. Furthermore, as the client cannot compare the EPR that is returned with its cache of already used EPRs, and because the client doesn't know whether it deals with a "smart" or "dumb" resolution service, it can only just try and give up after a number of attempts if it doesn't work. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

#1745 resolve-abstract-name TO IRI-to-EPR
by Frank Siebenlist 28 Apr '06

28 Apr '06

Summary: #1745 resolve-abstract-name TO IRI-to-EPR Tracker: Naming Comments by Frank Description: the IRI passed to the "resolve-abstract-name" should not be specific to an "AbstractName", but should be defined for generic "IRI-to-EPR" resolution. The IRI might alternatively be derived from the Address+RefParameters, or may have been communicated through many different ways that are different from EPR embedding. Andrew Grimshaw (2006-03-16 13:00:50) I disagree most strongly. The whole point of that porttype WS_Name resolveAbstractName(AbstractName) is to work with abstract names that are explicitly comparable without having to resort to using RefParameters. If someone wants to do as suggested - then they should use the other resolution port EPR resolve([EPR]) and pass in the EPR. Frank: Please read my comment again... It states that the interface should be useful for any URI/IRI, not "just" the abstract-name. In other words, "your" abstract name is just one possible URI to identify the resource and there maybe many, many more, and of those, there could be one or more that can be used to resolve. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

#1744 Resolver Port Type Rename
by Frank Siebenlist 28 Apr '06

28 Apr '06

Summary: #1744 Resolver Port Type Rename Tracker: Naming Comments by Frank Description: change the portType name to indicate that this is a resolution to EPRs, like EprResolverInterface and EprRenewableReference, because there are many possible resolutions/resolvers and the porttype-name "Name" doesn't tell you much Andrew Grimshaw (2006-03-16 12:57:52) I'm not sure I understand the question - though I believe the spec as modified reflects the desire - i.e., that the two resolution porttypes explicitly have different "types" - one returns a WS-Name, the other a vanilla EPR. Frank: So we differentiate by return type... isn't the operation name a more intuitive way to address semantical meaning? -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0