1 / 8

OGSA-EMS GGF17 May, 2006 in Tokyo, Japan Andrew Grimshaw

OGSA-EMS GGF17 May, 2006 in Tokyo, Japan Andrew Grimshaw. GGF Intellectual Property Policy.

happy
Télécharger la présentation

OGSA-EMS GGF17 May, 2006 in Tokyo, Japan Andrew Grimshaw

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OGSA-EMS GGF17 May, 2006 in Tokyo, Japan Andrew Grimshaw

  2. GGF Intellectual Property Policy All statements related to the activities of the GGF and addressed to the GGF are subject to all provisions of Appendix A of GFD-C.1, which grants to the GGF and its participants certain licenses and rights in such statements. Such statements include verbal statements in GGF meetings, as well as written and electronic communications made at any time or place, which are addressed to any GGF working group or portion thereof, Where the GFSG knows of rights, or claimed rights, the GGF secretariat shall attempt to obtain from the claimant of such rights, a written assurance that upon approval by the GFSG of the relevant GGF document(s), any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms. The working group or research group proposing the use of the technology with respect to which the proprietary rights are claimed may assist the GGF secretariat in this effort. The results of this procedure shall not affect advancement of document, except that the GFSG may defer approval where a delay may facilitate the obtaining of such assurances. The results will, however, be recorded by the GGF Secretariat, and made available. The GFSG may also direct that a summary of the results be included in any GFD published containing the specification.

  3. Agenda Bashing • HPC profile as driving use-case • BES/ESI discussions • Close

  4. HPC Profile

  5. BES/ESI integration • In April Foster and Snelling introduced the ESI (Execution Services Interface) document to OGSA & OGSA-BES • At first there was a great deal of confusion about the intent of the document • Once the dust settled, progress was possible • Phone calls to discuss ESI document in the context of BES • Positive

  6. OGSA-BES/ESI Discussion Decisions • State model of BES is not well described, nor does it capture richness desired by ESI. • Decision: We will redo the state model based on consensus – AND do a state table rather than a diagram. • Comment: Need to synch SAGA state machine and ideas expressed by Theimer et al on state unions. • Idempotence. • Decision: BES will incorporate the idempotence option. However, over what time interval is still an issue. • Resource model • Decision: Drop in ESI 4..1 as the BES resource model • Job interface. • Decision: The “type” of the EPR returned by CreateActivityfromJSDL is out of scope for BES. Thus the managedjobinterface is out of scope. But – it does not preclude BES containers from returning EPR’s of “type” managemed job interface. And a spec for managed job interface would be welcome … indeed a POSIX-manage-job interface would be welcome.

  7. More decisions • To add a HOLD state. Clarify the suspend state and clarify the state transition table with a table. • Change the CreateActivityFromJSDL to allow holds on any/all states. (Don't proceed past the specified states). • Notification. • Decision - Change CreateActivityFromJSDL to add another argument that is a reference to a Notification. We should have document type that has the JSDL document inside it and there should be a Notification area. We need to come up with a name of the wrapper element. We need to think about extending JSDL or adding a wrapper document. This will be discussed on the email list and a discussed next week. If a notification is specified and the container cannot handle it then it should fault. • Hold states * Notification on Submit • BES supports something approaching this by submitting into a suspended state at which point notification is set up. There is a gap here between BES and ESI functionality. • Decision - See above.

  8. Next steps • Carry through on document modifications (started) to reflect decisions. • Three immediate issues • Hashing out the state model – I like what Marvin presented • Hashing out the resource model – my preference is to use the ESI model – and let it get argued about in public comments • Writing the separate “managed job” specification • Get commitments from players to implement

More Related