- jsdl-wg - lists.ogf.org

Minutes for the Activity Instance session
by Alexander Papaspyrou 18 Sep '08

18 Sep '08

All, I cleaned up my minutes mess from yesterday. Where I was unsure regarding a certain aspect, I added a name in brackets; please approve whether I cited correctly what you intended to say. Whatever I have got tomorrow at noon, I will upload to the session page and to GridForge. Thanks, Alexander ======================== Activity Instance Schema ======================== Remote Participants: Fred Brisard ------- Agenda: ------- - Review of work so far (background, objectives) - Update on use cases - Discussion of requirements list - Next steps towards strawman -------- Minutes: -------- Requirements: - The general notion of "dependency" and "workflow" handling needs more clarification * clean separation between plain activities that have passive dependencies to each other and nested activities, which might have a "parent" activity and possibly spawn new sub-activities themselves * streamlining of names in the whole area --> no consensus whether this should be part of AI schema at all; discussion postponed to later - Changes to the original template during the lifetime of an activity could be tracked along with its state [Andreas?] - Generated data is not supposed to go directly into the schema. This covers e.g. predicted end times for activities and the like. However, it might be good to capture "intermediate" states (pending a clear definition [Fred?]). It is agreed upon that whatever is available currently (e.g. the BES state model) suffices - The notion of "sealing" an activity implies a read-only mode for the activity document which is to be enforced by the service providing the document. - "Final records" (for usage data etc.) might appear more than once; naming of such should be rethought. - Security is to be handled outside the activity document, possibly providing an additional security document along with the activity document. On-behalf access models common in Grids are to be considered. There might be a need for fine-grained ACLs, but this is still unclear. --> issue needs more discussion and consultation of security people - R019 was dropped, since it is already captured by R001 and R002 [Philipp?] - Resource usage tracking should be kept low profile, since the necessary information may or may not be available. - Exceptional states probably do not need to be represented by a separate concept, but could be handled as a part of the state recording. In general, a reason blob should suffice. - Checkpointing is to be handled in terms of capturing the state only, without coming up with a model. Possibly, this can be even handled as part of the state records of an activity [Andreas?]. - Data locations need clarification. - Capturing the state of sub-activities is a sub-problem of the question how to handle dependencies and workflows. There seems to be a strong necessity for being able to at least "find out" about incoming and/or outgoing dependencies, which in turn is part of nesting of activities. Possibly, a parent/child relationship which also implies ownership will be sufficient. General Comments: - A document split into use cases/requirements and schema/spec has been suggested to allow for additional/complementary specs on the basis of the same requirements and use cases. - During the forging of the specification, it would be beneficial to find two implementors that can accompany the definition process in order to ensure early that all concepts can be implemented. - The requirements should be streamlined and clarified as far as possible in order to get a core specification without bells and whistles -------- Actions: -------- Philipp, Alexander (ASAP): - consolidate requirements list - clean up wording - extend descriptions - come up with draft schema, starting from UDAP Group Discussion - prioritize list, using high/medium/low - continue bi-weekly calls for work

1 0

Minutes for the Activity Instance session
by Alexander Papaspyrou 18 Sep '08

18 Sep '08

All, I cleaned up my minutes mess from yesterday. Where I was unsure regarding a certain aspect, I added a name in brackets; please approve whether I cited correctly what you intended to say. Whatever I have got tomorrow at noon, I will upload to the session page and to GridForge. Thanks, Alexander ======================== Activity Instance Schema ======================== Remote Participants: Fred Brisard ------- Agenda: ------- - Review of work so far (background, objectives) - Update on use cases - Discussion of requirements list - Next steps towards strawman -------- Minutes: -------- Requirements: - The general notion of "dependency" and "workflow" handling needs more clarification * clean separation between plain activities that have passive dependencies to each other and nested activities, which might have a "parent" activity and possibly spawn new sub-activities themselves * streamlining of names in the whole area --> no consensus whether this should be part of AI schema at all; discussion postponed to later - Changes to the original template during the lifetime of an activity could be tracked along with its state [Andreas?] - Generated data is not supposed to go directly into the schema. This covers e.g. predicted end times for activities and the like. However, it might be good to capture "intermediate" states (pending a clear definition [Fred?]). It is agreed upon that whatever is available currently (e.g. the BES state model) suffices - The notion of "sealing" an activity implies a read-only mode for the activity document which is to be enforced by the service providing the document. - "Final records" (for usage data etc.) might appear more than once; naming of such should be rethought. - Security is to be handled outside the activity document, possibly providing an additional security document along with the activity document. On-behalf access models common in Grids are to be considered. There might be a need for fine-grained ACLs, but this is still unclear. --> issue needs more discussion and consultation of security people - R019 was dropped, since it is already captured by R001 and R002 [Philipp?] - Resource usage tracking should be kept low profile, since the necessary information may or may not be available. - Exceptional states probably do not need to be represented by a separate concept, but could be handled as a part of the state recording. In general, a reason blob should suffice. - Checkpointing is to be handled in terms of capturing the state only, without coming up with a model. Possibly, this can be even handled as part of the state records of an activity [Andreas?]. - Data locations need clarification. - Capturing the state of sub-activities is a sub-problem of the question how to handle dependencies and workflows. There seems to be a strong necessity for being able to at least "find out" about incoming and/or outgoing dependencies, which in turn is part of nesting of activities. Possibly, a parent/child relationship which also implies ownership will be sufficient. General Comments: - A document split into use cases/requirements and schema/spec has been suggested to allow for additional/complementary specs on the basis of the same requirements and use cases. - During the forging of the specification, it would be beneficial to find two implementors that can accompany the definition process in order to ensure early that all concepts can be implemented. - The requirements should be streamlined and clarified as far as possible in order to get a core specification without bells and whistles -------- Actions: -------- Philipp, Alexander (ASAP): - consolidate requirements list - clean up wording - extend descriptions - come up with draft schema, starting from UDAP Group Discussion - prioritize list, using high/medium/low - continue bi-weekly calls for work

1 0

JSDL 1.0 Recommendation status (was Fwd: [ogsa-hpcp-wg] HPCBP and BES 1.0 are now complete)
by Andreas Savva 18 Sep '08

18 Sep '08

FYI. ------- Forwarded message ------- From: "Steven Newhouse" <Steven.Newhouse(a)microsoft.com> To: "ogsa-hpcp-wg(a)ogf.org" <ogsa-hpcp-wg(a)ogf.org>, "ogsa-bes-wg(a)ogf.org" <ogsa-bes-wg(a)ogf.org> Cc: Subject: [ogsa-hpcp-wg] HPCBP and BES 1.0 are now complete Date: Thu, 18 Sep 2008 12:53:12 +0900 All, At OGF24 this week, the Standards Council reviewed the experimental documents relating to the: * HPC Basic Profile 1.0 * HPC Profile Application Extension 1.0 * Job Submission Description Language 1.0 * Basic Execution Service 1.0 With the evidence contained within the experimental documents relating to the implementation and interop experiences, these specifications were moved from the 'provisional' to 'full' OGF Recommendations. Many thanks to the OGF community for their engagement in this activity over the years. The documents and their status on the OGF website will be updated over the next few days. Steven -- ogsa-hpcp-wg mailing list ogsa-hpcp-wg(a)ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg -- Andreas Savva Fujitsu Laboratories Ltd

1 0

FINAL CALL: Parameter sweep extension (to Sep. 19)
by Andreas Savva 15 Sep '08

15 Sep '08

This is the final call for the parameter sweep extension. If you have any comments please send them to the list before Sep. 19, 2008 (next week Friday). After this working group final call finishes the document will be submitted to the OGF Editor and enter the process for official publication. As part of this process a formal public comment period will also be carried out. Attached pdf corresponds to this gridforge entry https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.jsdl-wg/… -- Andreas Savva Fujitsu Laboratories Ltd

3 3

Teleconference minutes - 10 September 2008
by Andreas Savva 10 Sep '08

10 Sep '08

Minutes on gridforge. https://forge.gridforum.org/sf/go/doc15332?nav=1 -- Andreas Savva Fujitsu Laboratories Ltd

1 0

JSDL Teleconference - 10 September 2008 **@2pm UTC**
by Andreas Savva 10 Sep '08

10 Sep '08

Confirming a call for Wednesday, 10 September, at *2pm UTC*. Agenda: 1. Agenda bashing 2. Status updates/technical discussion - JSDL Experience document - Parameter sweep - Activity instance document schema 3. OGF24 session preparation ===== Full call-in details ==== Date: 10 September 2008 Time: UTC 2 PM EUROPE: BST 3 PM / CEST 4 PM US: EDT 10 AM / PDT 7 AM ASIA: JST / KST 11 PM Duration: 1 hour Dial-in numbers (toll): US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 207 3655269 (London) Germany: +49 (0)69 50070802 (Frankfurt) Japan: +81 3 3570 8225 (Tokyo) Other countries: http://tinyurl.com/eg48j User guide: http://tinyurl.com/qknrf Teleconference participant PIN: 4371991 Screen share: http://jsdl.glance.net/?key=0910 Note: When you dial in after the initial message in English for the PIN there is another message in Japanese only (sorry) to state your name and press '#' in order to join the call. -- Andreas Savva Fujitsu Laboratories Ltd

2 1

ParameterSweep draft 20
by geoff 05 Sep '08

05 Sep '08

Hi folks, Very small minor wording change to specification document (chapter 3.1, paragraph 2) reflecting closure of artifact 6271 (DocumentNode needs explicit namespace bindings) as per previous email. New draft 20 (version 14) available at http://forge.ogf.org/sf/go/doc14595?nav=1 gef

2 2

g-Eclipse implement sweep extension
by Mariusz Wojtysiak 04 Sep '08

04 Sep '08

Hello! I'm proud to announce that in g-Eclipse project we are implementing handling of parametric jobs using JSDL-sweep extension. Now using our JSDL editor, user can: 1. Create basic JSDL (see 1.CreateJSDL.PNG, 2.CreateJSDLStagers.PNG) 2. Select elements, which will be parametrized using sweep extension (see 3.CreateParameterSrcURI.PNG, 4.NestedParameters.PNG) 3. As a result user has JSDL with sweep extension (see5.SweepSource.PNG) Then user can: 4. Submit such parametrized JSDL to any middleware (currently gLite and GRIA are supported). As a result individual JSDLs are generated by g-Eclipse and every JSDL is submitted to middleware (see 6.SubmittedJobs.PNG) In first version generation of JSDLs is done on client side, but if middleware support somehow parametric jobs, we want to send such parametric-JSDL directly to middleware. In last g-eclipse release we implemented sweep extension using http://schemas.ogf.org/JSDL/2007/01/JSDL-sweep what isn't the newest version of JSDL draft. There are still missing: - loops (user can only specify Values in functions) - error handling (e.g. nothing special happens when user not specify values for parameter) In next g-eclipse version we plan to add loops. What are your plans about sweep specification? When we can expect specification in stable version, which we could implement? If you would like to try g-eclipse, just go to: http://www.geclipse.eu/index.php?id=12&backPID=74&tt_news=44 -- Regards, Mariusz Wojtysiak g-Eclipse team

2 1

JSDL Experience Document
by Stephen McGough 04 Sep '08

04 Sep '08

Dear All, I'm pleased to present the latest draft of the JSDL Experiences Document (attached). We're trying to get this document into public comment quickly so shall (depending on comments) submit it after next Friday. So could people please send comments (to the list) by end of day Friday 4th July 2008. We shall also discuss this on the call next week. Many thanks, steve.. (on behalf of the group) -- ------------------------------------------------------------------------ Dr A. Stephen McGough http://www.doc.ic.ac.uk/~asm ------------------------------------------------------------------------ Technical Coordinator, London e-Science Centre, Imperial College London, Department of Computing, 180 Queen's Gate, London SW7 2BZ, UK tel: +44 (0)207-594-8409 fax: +44 (0)207-581-8024 ------------------------------------------------------------------------

4 5

ParameterSweep draft 19
by geoff 29 Aug '08

29 Aug '08

Hi folks, There's been a very minor change to sweep.xsd in the draft relating to artifact 6269 ( http://forge.ogf.org/sf/go/doc14595?nav=1 ). Artifacts 6148 (Matching output with sweep indexes?) and 6269 (Check required extensibility to support constraints) have now been closed. gef

1 0