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

summary of topology thread
by Karl Czajkowski 13 May '05

13 May '05

As promised on the telecon, I try to summarize the "topology thread." The basic status is that Chris and I seem to be in agreement about a range of resource constraints that need expression and there is a minor open question about how (if at all) the binding of application to resource is expressed. I have talked to Chris and others from Platform a lot over the years, so I guess it is not clear whether we've made progress explaining this position to others. :-/ PROPOSED SET OF CONCEPTS What Chris and I think is that there are three critical concepts that need expression and they all relate to what allocation the job will receive. We think these should be expressed in the resource section: A. Total Number of CPUs for job B. Number of CPUs per resource (e.g. per LSF host) C. Total Number of resources I think both (B) and (C) are tiling constraints and need to default to "unconstrained" if left out of the JSDL doc. It is important to note that by expressing all of (A), (B), and (C) one can overconstrain the selection, e.g. describe redundant things or impossible things. We think this is OK and maybe even necessary in order to allow expression of the important things. All three values should be range-value for generalized constraints w/ step values, limits, etc. Another minor point is whether we want to express shared/exclusive access to resources. Saying "4 CPUs per resource" DOES NOT mean that all allocated hosts will have 4 installed CPUs. It means the job is granted the right to use 4 of the CPUs, but there could be more which are kept idle or allocated to other jobs. REPRESENTATION OF CONCEPTS The total value (A) is the difficult one, because it applies across all Resource elements but does not really belong in the Application section in our view. I suggest that a wrapping layer could be placed around Resource: <jsdl:Resources> <jsdl:TotalCPUs>jsdl:rangeValue</jsdl:TotalCPUs> ? ... other totals for RAM, VM, etc. ... <jsdl:Resource> <jsdl:Count>jsdl:rangeValue</jsdl:Count> ? <jsdl:CPUs>jsdl:rangeValue</jsdl:CPUs> ? ... other per-resource constraints ... </jsdl:Resource> + </jsdl:Resources> Make jsdl:TotalCPUs default to "<exact>1</exact>". Make jsdl:Count and jsdl:CPUs default to unconstrained. The remaining question, again, is how to represent the binding of application to resource. This is where the GRAM single/multi/mpi/condor stuff fits in to state different launch techniques. It might be appropriate to say the default is "site specific" and a reasonable assumption is that a real resource topology is selected by the scheduler and somehow communicated to the job in the form of a resources file, environment setting, or actual process set startup. One can imagine arbitrarily strange and complex scenarios here for the interesting cases. USE CASES TO ILLUSTRATE CONCEPTS Chris made a nice concise statement of use cases that need to be addressed, and I think the implication is that JSDL examples should use these cases rather than existing confusing ones: 1. Simple MPI job. Wants 32 processors with 1 processor per resource (in JSDL, a host is a "resource"). <jsdl:Resources> <jsdl:TotalCPUs><exact>32</exact></jsdl:TotalCPUs> ... <jsdl:Resource> <jsdl:CPUs><exact>1</exact></jsdl:CPUs> ... </jsdl:Resource> </jsdl:Resources> <jsdl:Resources> <jsdl:TotalCPUs><exact>32</exact></jsdl:TotalCPUs> ... <jsdl:Resource> <jsdl:Count><exact>32</exact></jsdl:Count> ... </jsdl:Resource> </jsdl:Resources> <jsdl:Resources> <jsdl:TotalCPUs><exact>32</exact></jsdl:TotalCPUs> ... <jsdl:Resource> <jsdl:Count><exact>32</exact></jsdl:Count> <jsdl:CPUs><exact>1</exact></jsdl:CPUs> ... </jsdl:Resource> </jsdl:Resources> All three of these lead to exactly the same set of possible allocations. I will not show equivalent permutations for the rest of the examples but this gives the basic idea. 2. OpenMPI job. Wants 32 processors with 8 processors per resource. <jsdl:Resources> <jsdl:TotalCPUs><exact>32</exact></jsdl:TotalCPUs> ... <jsdl:Resource> <jsdl:CPUs><exact>8</exact></jsdl:CPUs> ... </jsdl:Resource> </jsdl:Resources> 3. An OpenMP job. Wants 32 processors. Shared mem of course, so one resource. <jsdl:Resources> <jsdl:TotalCPUs><exact>32</exact></jsdl:TotalCPUs> ... <jsdl:Resource> <jsdl:Count><exact>1</exact></jsdl:Count> ... </jsdl:Resource> </jsdl:Resources> 4. A "homegrown" master/slave parallel job (say a ligand docking job). Wants 32 processors. No tiling constraints at all. <jsdl:Resources> <jsdl:TotalCPUs><exact>32</exact></jsdl:TotalCPUs> ... <jsdl:Resource> ... </jsdl:Resource> </jsdl:Resources> * Note that I'm specifically leaving out the Naregi "coupled simulation" use case (sorry guys), since we determined at the last GGF that it was a case which could be decomposed into multiple JSDL documents. Of course, these use cases leave out many interesting "loose" constraints where range-value is used to allow many possibly heterogeneous solutions to the constraint system of the JSDL doc. I would add that I think the "coupled simulation" use case can be addressed by the resource constraints we are proposing but it is in the "binding of application to resource" where multiple JSDL docs are required. For example, we can select heterogeneous resources if the single application knows how to run each different "simulation" on subsets of the allocation without expressing that binding in JSDL: <jsdl:Resources> ... <jsdl:Resource> <jsdl:Count><exact>8</exact></jsdl:Count> <jsdl:CPUs><exact>2</exact></jsdl:CPUs> ... </jsdl:Resource> <jsdl:Resource> <jsdl:Count><exact>16</exact></jsdl:Count> <jsdl:Count><exact>1</exact></jsdl:Count> ... </jsdl:Resource> </jsdl:Resources> If we wanted to address such complex scenarios more elegantly, we could allow more than one Resources element or even allow Resources elements to recursively contain Resources elements in order to express logical assemblies of resources which scope the "total" constraints expressed within them as a summation of the contained assemblies or "leaf" resource elements. I do not know if anyone cares about this sort of hierarchical resource map. karl -- Karl Czajkowski karlcz(a)univa.com

3 7

JSDL compliance levels
by Michel Drescher 04 May '05

04 May '05

Folks, I got the assignment to the following two action points from last week's phone conference: >> 8) JSDL compliance levels >> How much of jsdl a system must support, not just process. >> Probably a topic for later. >> >> 9) The statement "If not supported then the consuming system MUST >> reject the document." needs a bit more explanation or re-write To solve these action points, I refer to the specification document (v0.8.5-02) ch 2 "Notational conventions". I propose to replace the chapter's last three paragraphs (the text after table 1) with the following paragraphs: "The term JSDL documentrefers to a XML document that has been created following this specification. It is a schema instance document derived from the normative schema definition inAppendix 2:Normative Schema. The terms JSDL element and JSDL attribute indicate that the corresponding language construct is represented as an XML element and XML attribute in a JSDL document. The key word presentrefers to a construct being present in a JSDL document. The key word support refers to a consuming system being able to apply the following functions to a JSDL element or JSDL attribute: · Parse the JSDL element or JSDL attribute into a DOM tree · Validate the parsed DOM tree against the appropriate schema(s) · Interpret the JSDL element or attribute and assign the semantics according to this specification. The JSDL specification does not require the consuming system to actually implement the semantics of JSDL elements and attributes, so that the described job is executed on a computing system. A consuming system MUST support all normative JSDL elements and JSDL attributes. If a consuming system implements JSDL, it MUST implement all defined JSDL elements and attributes. This allows not only systems that execute jobs but also systems that provide higher level services, for example job broker, super scheduling systems (that possibly change JSDL documents before they get submitted to lower level job execution systems), etc." Note: The last paragraph possibly fits better in a JSDL primer document. This way any consuming system that deals with JSDL must support the defined JSDL elements and attributes, but it does not need to "ground" or "incarnate" or even execute a JSDL job. But if it implements JSDDL, then all JSDL elements and attributes must be implemented. So this basically eliminates any JSDL compliance levels. As we already reduced JSDL to the lowest common denominator, there is no need of compliance levels at all - at least for the moment. The consequence would be that we can delete all these "If not supported then ... " sentences. Cheers, Michel

2 1

a couple of questions
by Ariel Oleksiak 29 Apr '05

29 Apr '05

Hi All, That's me again. Please find another portion of questions and comments concerning the latest versions of JSDL specification and schema. These issues arisen mainly when we were trying to map JSDL to other job description languages. 1. In one of my previous emails I asked about specification of a directory in the DataStaging element and I got the answer that this is possible. Therefore, in my opinion, what we need is the attribute which distinguishes between regular file and a directory. I think that a scheduler may often need this knowledge to perform data staging (e.g. it may have to know whether a given logical name is the name of file or directory in order to call appropriate methods of a data management system). 2. I guess the NetworkBandwidth element defines the maximal bandwidth of the networking interface for a given resource. Such a metric is rather useless in a resource selection process because indeed only the actual bandwith between two nodes is really important. So didn't you think about the element defining bandwith between two nodes, e.g. containing an attribute to specify the second node? 3. Some time ago we discussed defining of software dependencies, e.g. necessary libraries etc. and I sent some simple use-cases. I do not see this element in the spec. Have you come to the conclusion that this is not general enough? 4. What is the meaning of the "other" value in the list of OSs, processor architectures etc.? Does it mean that (i) a scheduler has to select resources limited to those having OS OTHER than the remaining OSs from the list or (ii) that a certain OS, not included in the list, is required and its exact name is included in an additional element (which one?). In my opinion the latter is more rational (actually I don't see any use case for the former) but, if so, how this OS should be specified - using the Description element, extension? 5. The next question is related to the semantics of resource requirements in JSDL. Are resource requirements limited to required amounts of resources available for user's application (e.g. free CPUs, free memory etc.) in a given point of time or they also enable a user to specify required total amounts of resources (e.g. total number of CPUs, total virtual memory etc.)? Of course the former (dynamic) values are much more important during resource selection, however, information about some of them may not be available in all grid environments. Anyway this distinction must be clearly defined. 6. I see that units and operators attributes disappeared from the schema. I understand that operators can be expressed using RangeValueType and units are defined in the specification now? 7. It is not clear for me what is the difference between Range elements and Upper/LowerBoundedRange in the RangeValueType. Sorry if it has been already explained elsewhere. 8. I cannot find a way to specify a type of application in terms of its architecture (single, mpi etc.). I suppose that you consider it as too specific and as a possible extension or maybe this is an oversight? Thanks, Ariel

2 1

CIM Reference (Again)
by Donal K. Fellows 27 Apr '05

27 Apr '05

The CIM reference I was using at the F2F was a preliminary release of CIM 2.9, and currently we're only using the operating system types from them (in their human-readable versions[*]). There is also a processor typing model available, but it's just about unusable from our PoV because CIM does not support partial order relations on its enumeration types. (The problem is also there with OSes, but the amount of cross-emulation is much less.) The enumeration was taken from the ValueMap for System -> Operating System -> CIM_OperatingSystem -> OSType part of the overall model (Device sub-model, Operating System page, CIM_OperatingSystem class, OSType field), though it is necessary to read the MOFs or the XML to actually get the values. (Messy!) The processor part of the model would be the ValueMap from Device -> Processors -> Processor -> Family, except I find it hard to see many people being happy at distinguishing between "AMD Athlon(TM) 64 Processor Family" and "AMD Opteron(TM) Processor Family" for almost all applications! The reference to the final version of CIM 2.9.0 is at http://www.dmtf.org/standards/cim/cim_schema_v29 but I actually used http://www.dmtf.org/standards/cim/cim_schema_v29_prelim if that matters. Note that as far as we're concerned, I think updates to the list of OS types shouldn't be a problem. Donal. [* The core model is actually numeric, but we really don't want to go that route; it overexposes the underlying implementation details. ]

1 0

JSDL: Today's telecon minutes
by Ali Anjomshoaa 26 Apr '05

26 Apr '05

Hi everyone, today's telecon minutes are on GridForge at: https://forge.gridforum.org/projects/jsdl-wg/document/Minutes_-_2005-04-26/… For those on the call, your actions are in the minutes. Please ask for help on the list with feedback or effort. Thanks everyone. Cheers and take care, Ali -- ---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali(a)epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------

1 0

Limit Text
by Donal K. Fellows 26 Apr '05

26 Apr '05

The following is my suggested text for the MemoryLimit and PipeSizeLimit element definitions. The text in [brackets] is non-normative. I have omitted the text stating what it must be a sub-element of (according to the principles of allowing the schema to be used as an ontology as well as a document definition) but if we really want that, it's trivial to add it. MemoryLimit: Definition This element is a positive integer that describes the maximum amount of physical memory (in bytes) that the job should use when executing. It MUST be supported. If this is not present, then it is unlimited. [This is really the Resident Set Size limit, and systems might impose a granularity of a kilobyte.] PipeSizeLimit: Definition This element is a positive integer that describes the maximum size of pipelines (in bytes) created for and by the processing of the job. It MUST be supported. If this is not present, then the system should use its default value. [No system permits arbitrary sized pipe buffers, but their defaults are usually entirely acceptable. Systems typically impose a granularity of 512 bytes.] Donal.

1 0

Coupling PosixApplication to DataStaging
by Donal K. Fellows 26 Apr '05

26 Apr '05

Hi everyone! We have something of a problem in that we need a way to join the virtual filesystem locations that we stage files to/from in DataStaging to the places referred to in various places in PosixApplication (especially Argument and Environment, though this also applies to Input, Output and Error; possibly WorkingDirectory too). The problem is that we want to virtualize the location within the real target filesystem(s) that the files are located in, but we do not have any standard substitution scheme; so far, we've only got the ability to specify literal strings which gives either absolute locations (non-portable) or locations that are relative to the working directory (great for the simple cases, but awful for anything complex). In DRMAA, this problem is solved by allowing magical tokens to be put at the start of applicable parameters and defining a substitution scheme for those magical parameters. (This is also the UNICORE approach). That works, but I use the term "magical" with good reason; the values are not easily manipulable with XML processing tools. The other basic alternative, processing with XSLT on the way in, has the problem in that it tends to end up binding things to specific locations far too soon. What I think we need is a way to say that a certain term is to be made relative to a particular virtual filesystem root. As far as I'm concerned, the easiest way of doing this is to put optional attributes on the elements needing this treatment (listed above) that say that the element value needs to be interpreted as being relative to the root of the virtual filesystem named in the attribute, with an absent attribute indicating that the attribute value is to be used literally. Alternatively, we could put a complex type inside the element, but that's much messier IMO. I suggest that the attribute should be called jsdl:filesystem (or rather, whatever we use in DataStaging but I don't remember for sure right now) and we might use it like this fragment: <jsdl:Application> <jsdl:ApplicationName> Gaussian </jsdl:ApplicationName> <jsdl-exec:POSIXApplication> <jsdl-exec:Input jsdl:filesystem="HOME"> input.txt </jsdl-exec:Input> <jsdl-exec:StackSpaceLimit> 8388608 </jsdl-exec:StackSpaceLimit> </jsdl-exec:POSIXApplication> </jsdl:Application> We'd need to decide what predefined virtual filesystems to support, of course. Or have we done that already? :^) Donal.

2 2

OGSA-BES group
by Darren Pulsipher 26 Apr '05

26 Apr '05

For everyone's information the OGSA-BES group is having meetings on Thursday Mornings at the same time as the JSDL meetings on Tuesdays. To join the email list send mail to majordomo(a)ggf.org subscribe ogsa-bes-bof Darren

1 0

JSDL
by Darren Pulsipher 26 Apr '05

26 Apr '05

When: Tuesday, Apr 26, 2005 8:00 AM (MDT) Where: On Line *~*~*~*~*~*~*~*~*~* Here is the web conference for tomorrow -+-----+-----+-----+-----+-----+-----+-----+-----+- Darren Pulsipher has invited you to attend a Microsoft Office Live Meeting. Subject: JSDL Meeting URL: https://www.livemeeting.com/cc/xangoit/join Meeting ID: KC2MK6 Attendee Key: S|h:@K<9K Role: Attendee This Office Live Meeting invitation is a personal invitation meant only for you. It should not be forwarded. If you received this email by mistake or require Live Meeting Assistance, please refer to the Live Meeting Assistance Center at http://r.office.microsoft.com/r/rlidLiveMeeting?p1=7&p2=en_US&p3=LMInfo&p4=…

1 0

RE: JSDL Meeting on Apr 26 2005
by Bill Harris 25 Apr '05

25 Apr '05

Audio for meeting on Tuesday information 1 800-933-3594 at message dial 3000 id is 6444 and confirmed ;-) Talk to you in the morning William Harris Program Architect Oryx follow me - 800 281 6462 Inside cadence 88 202 6462 Cell Phone 801 301 2744 The contact details are: Dial In Numbers: Belgium - 0800-7053 Bezeq - 1-800-940-1786 France - 0800-903109 Germany - 0800-1815765 Hong Kong - 800-968932 Italy - 800874509 Japan - 00531123656 Korea-Tele - 00798-14-800-0512 Netherlands - 0800-0225447 Singapore - 800-1200766 Sweden - 020-7905043 Taiwan - 00801-13-8546 UK - 0800961294 US - 800-933-3594 --> ext 3000 pin: 6444 The telecom time is: wed April 26 this week 07:00 PST 08:00 MST 09:00 CST 10:00 EST 15:00 BST 16:00 CET 23:00 JST William Harris Program Architect Oryx follow me - 800 281 6462 Inside cadence 88 202 6462 Cell Phone 801 301 2744

1 0