- ogsa-bes-wg - lists.ogf.org

BES Agenda at OGSA F2F
by Steven Newhouse 08 Aug '05

08 Aug '05

As discussed at the last call the provisional agenda for the BES part of the F2F (Monday 10.30-15.00) 0. Agenda bashing [10 mins] 1. Review of current draft & discussion [50 mins] 2. Discussion about renderings [60 + 60 mins] 3. Discussion about implementations [30 mins] Consider this a stake in the ground! Steven -- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Deputy Director, Open Middleware Infrastructure Institute (OMII) Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK

1 0

WS-GRAM protocol sketch, as promised on telecon
by Karl Czajkowski 05 Aug '05

05 Aug '05

This is excerpted from a larger summary I sent to the BES BoF list back at the beginning of the year... it shows the "boxcar" submission+subscription mechanism as well as the hold/release mechanism. I've left out extra content that was in the previous email to focus on these parts. Note, WS-GRAM currently has only one "hold" state that is used for synchronizing _cleanup_ of jobs. It would be meaningful to have a _startup_ hold state such as we had in previous GRAM protocols, but it is not strictly necessary for reliable invocation because we use the idempotent message-id idiom instead. Also, keep in mind that the subscription patterns works because we are using WSRF style rendering w/ properties and topics defined for the job resource. So, the semantics are quite clear: create the job resource and then invoke the subscription operation on it w/ the arguments embedded in the creation message. Please see the Globus website documentation, for example, http://www-unix.globus.org/toolkit/docs/4.0/execution/wsgram/developer/WS_G… for examples of client-side programming to build up and send such protocol messages. karl --------------------------------------------------------- PORTTYPE ManagedJobFactoryPortType ---------- OPERATION job:createManagedJob Request creation of a Managed Executable Job Resource whose EPR will be returned in the response. INPUT message: createManagedJobInputMessage has one part: <createManagedJob> <InitialTerminationTime>xsd:dateTime</InitialTerminationTime>? <JobID>wsa:AttributedURI</JobID>? <wsnt:Subscribe></wsnt:Subscribe>? <desc:job> ... </desc:job> </createManagedJob> The optional JobID element is used to request idempotent invocation semantics in a binding-independent manner. The optional wsnt:Subscribe element is used to request automatic subscription to the newly created Managed Job. This call can also create a Managed Multi-Job Resource, i.e. a co-allocated job spread across multiple WS-GRAM hosts, because the job element is actually in an XSD choice with a multijob element. OUTPUT message: createManagedJobOutputMessage has one part: <createManagedJobResponse> <NewTerminationTime>xsd:dateTime</NewTerminationTime> <CurrentTime>xsd:dateTime</CurrentTime> <managedJobEndpoint>wsa:EndpointReferenceType</managedJobEndpoint> <subscriptionEndpoint>wsa:EndpointReferenceType</subscriptionEndpoint>? </createManagedJobResponse> The optional subscriptionEndpoint is returned if a corresponding subscription request was included in the input. --------------------------------------------------------- PORTTYPE ManagedExecutableJobPortType A Managed Executable Job Resource (MEJR) represents one job that has already been submitted by a client. It is a WSRF style resource with a resource properties document to represent status of the job: <managedExecutableJobResourceProperties> <stdoutURL>xsd:anyURI</stdoutURL>? <stderrURL>xsd:anyURI</stderrURL>? <credentialPath>xsd:string</credentialPath>? <exitCode>xsd:int<exitCode/>? <serviceLevelAgreement> <desc:job> ... </desc:job> </serviceLevelAgreement> <Capacity>xsd:int</Capacity> <userSubject>xsd:string</userSubject> <fault/> <TopicExpressionDialects>xsd:anyURI</TopicExpressionDialects> <Topic Dialect=xsd:anyURI> xsd:any? </Topic>+ <TerminationTime>xsd:dateTime</TerminationTime> <localUserId>xsd:string</localUserId> <CurrentTime>xsd:dateTime</CurrentTime> <holding>xsd:boolean</holding> <RegistrantData>xsd:base64Binary</RegistrantData> <RendezvousCompleted>xsd:boolean</RendezvousCompleted> <FixedTopicSet>xsd:boolean</FixedTopicSet> <state>Unsubmitted|StageIn|Pending|Active|Suspended|StageOut|Cleanup|Done|Failed</state> </managedExecutableJobResourceProperties> These properties relate to job output file management: stdoutURL, stderrURL delegated credential management: credentialPath parallel task rendezvous (for MPICH-G2): Capacity, RegistrantData, RendezvousCompleted job status: exitCode, fault, holding, state job introspection: credentialPath, serviceLevelAgreement, localUserId for WSRF introspection: TopicExpressionDialects, Topic, FixedTopicSet, TerminationTime, CurrentTime. ---------- OPERATION exec:release Releases job from hold state. The hold state is an optional behavior selected in the job description to prevent post-execution file deletions (clean-up) from occuring while a remote client is still attempting to access the files. The release operation permits the normal clean-up to occur. INPUT message: releaseInputMessage has one (empty) part: <release/> OUTPUT message: releaseOutputMessage has one (empty) part: <releaseResponse/> -- Karl Czajkowski karlcz(a)univa.com

1 0

Document Revision
by Steven Newhouse 26 Jul '05

26 Jul '05

All, On the call today we had: Steven Newhouse Michel Drescher Karl Czajkowski Fred Maciel Steve McGough Andrew Grimshaw Issues identified in the document that need to be discussed on the next call or on the list: Review: Section 3.2: Replacement of a general all encompassing fault with 'NotKnown' status that can be used within the ActivityStatus document to identify activities that are not known. Discussion: Section 3.2: Use of the CIM state enumerations. Discussion: Sections 3.5, 3.5 & 3.6. Having 3 management operations in the BES specification until generic OGSA management structure defined? Discussion: Section 3.7: When returning the JSDLDocuments do we place the WS-Name in the JSDLDocument or encapsulate it with the WS-Name in a new element? Review: Section 4: Text for exposing container acitivty. Review: Section 5: Text for security considerations. -- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Deputy Director, Open Middleware Infrastructure Institute (OMII) Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK

4 8

Re: [ogsa-bes-wg] Management Functions in BES
by Ian Foster 25 Jul '05

25 Jul '05

+2 At 09:39 AM 7/24/2005 -0400, Tom Maguire wrote: >+1 Karl > > >Freyâs Law: âEvery 5 years the number of architecture components >double and >the ability to comprehend them halvesâ > > >Perfection is achieved, not when there is nothing more to add, but when >there is nothing left to take away.Â Â Antoine de Saint-Exupery > >T o mÂ Â M a g u i r e > > >STSM, On Demand Architecture > > >Poughkeepsie, NYÂ 12601 > > > > Karl Czajkowski > <karlcz(a)univa.com > > To > Sent by: Steven Newhouse > owner-ogsa-bes-wg <s.newhouse(a)omii.ac.uk> > @ggf.org cc > ogsa-bes-wg(a)ggf.org > Subject > 07/24/2005 01:13 Re: [ogsa-bes-wg] Management > AM Functions in BES > > > > > > > > > > >On Jul 23, Steven Newhouse modulated: > > >Discussion: Sections 3.4, 3.5 & 3.6. Having 3 management operations in > > >the BES specification until generic OGSA management structure defined? > > > > The operations in 3.4 & 3.5 (Start & Stop AcceptingNewActivities) I see > > as being a service specific management function (i.e. they effectively > > alter the behavior of one specific operation within the service). > > > >While its semantics references a BES operation, it seems to me that it >is a more general management pattern for any service that has a >stateful, factory-like interface: stop accepting/creating new work >items but continue processing the existing ones (whatever they are). >The BES-specific meaning could just as easily be specified by calling >out this work acceptance model so that it can be related to an >external management mechanism. > >I think it is wrong to burden BES implementations with these kinds of >management functions that are specific to a hosting environment. I >think the right path here is to engage in management standards for web >services and create profiles to compose these with a basic execution >service if you require both. > >I cannot see these functions as being more important interop points >than any of the other security and policy management functions which >everyone seems to agree are out of scope. If you must use localized >mechanisms to do practical management of a BES installation, I am not >sure what these functions buy you. > > >karl > >-- >Karl Czajkowski >karlcz(a)univa.com _______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org

3 2

Regrets -- week of July 25-29
by Fred Maciel 23 Jul '05

23 Jul '05

Hi, On the week of July 25-29 I'll be in the SNIA/DMTF Technical Symposium. Regards, Fred Maciel Hitachi America R&D

1 0

embedding WS-Name in JSDL doc
by Karl Czajkowski 22 Jul '05

22 Jul '05

As promised on the call, here's a trivial BES spec. feature suggestion, in psuedo-schema format: <bes:ActivityName>..WS-Name content..</bes:ActivityName> which could be embedded in the JSDL doc in the JobIdentification section for correlation purposes when retrieving JSDL docs from the BES service: <jsdl:JobDefinition> <jsdl:JobDescription> <JobIdentification ...> <bes:ActivityName>..WS-Name content..</bes:ActivityName> </JobIdentification> <Application ...> ... this works because JobIdentification allows zero or more <xsd:any##other/> in its schema, e.g. any element that is defined in a namespace other than JSDL's namespace. karl -- Karl Czajkowski karlcz(a)univa.com

5 4

Fwd: [wsdm] Question about SituationCategory in MUWS part 2
by David Snelling 21 Jul '05

21 Jul '05

Folks, With respect to the Status state issue, you might find this interesting. The fact that CIM has not tried for extensibility, but WSDM have, as you have. Think carefully and do it right. Andreas' suggestion only allows for one level. You may be better off planing for proper nested extensibility. Begin forwarded message: > From: "Wilson, Kirk D" <Kirk.Wilson(a)ca.com> > Date: 20 July 2005 19:33:39 BST > To: "Murray, Bryan P." <bryan.murray(a)hp.com>, "Hiroyuki Masuda" > <masuda(a)soft.fujitsu.com>, <wsdm(a)lists.oasis-open.org> > Cc: <takagi.ryuichi(a)jp.fujitsu.com> > Subject: RE: [wsdm] Question about SituationCategory in MUWS part 2 > > Bryan, Hiroyuki, all, > > IMHO, the spec doesn't explain how to construct these taxonomies very > well (and perhaps the spec shouldn't), but I think it would be helpful > to have a discussion in the Primer that goes into more detail. After > struggling to figure out how this is done during some of my own writing > of the Primer, here's what I believe is the appropriate way of defining > each of the SituationCategories (I don't believe there are any child > relationship between these categories, which makes their definitions a > bit easier--they would follow the same pattern): > > <xs:element name="SituationCategoryDef" > type="muws-p2:SituationCategoryType"/> > > <xs:element name="XXXSituation"> > <xs:complexType> > <xs:complexContent> > <xs:restriction base="SituationCategoryDef " /> > </xs:complexContent> > </xs:complexType> > </xs:element> > > NOTE that SituationCategory is already defined in MUWS-P2 as a child > element of SituationType; thus, I believe I need a different name for > the GED for defining the Situation Categories. > > Recognizing hierarchical relationships between the elements your are > defining becomes a little tricker. > > Compare the definition of OperationStates in MOWS.) > > Kirk Wilson > Architect, Development > Office of the CTO > 802 765-4337 > > -----Original Message----- > From: Murray, Bryan P. [mailto:bryan.murray@hp.com] > Sent: Wednesday, July 20, 2005 1:13 PM > To: Hiroyuki Masuda; wsdm(a)lists.oasis-open.org > Cc: takagi.ryuichi(a)jp.fujitsu.com > Subject: RE: [wsdm] Question about SituationCategory in MUWS part 2 > > You are correct - the MUWS part2 schema should have definitions for > these elements. This was an oversight when the schema was written this > last spring. When we create a new version of MUWS after > WS-ResourceProperties, WS-BaseNotification are OASIS standards, we need > to add definitions for these global elements. If I remember right, the > definition will be similar to the following: > > <xs:element name="OtherSituation" type="muws-p2-xs:CategoryType"/> > > This allows the situations to have sub-categories if necessary or > desired. > > Bryan > > -----Original Message----- > From: Hiroyuki Masuda [mailto:masuda@soft.fujitsu.com] > Sent: Tuesday, July 19, 2005 11:59 PM > To: wsdm(a)lists.oasis-open.org > Cc: takagi.ryuichi(a)jp.fujitsu.com > Subject: [wsdm] Question about SituationCategory in MUWS part 2 > > Hi WSDM-TC members, > > My name is Hiroyuki Masuda. I'm "observer" member of WSDM-TC. > I have one question about SituationCategory in MUWS part 2. > > The following SituationCategory value is introduced at "2.5.1 Event > Format" in MUWS part 2. > > ------------------------------------------- > AvailabilitySituation > CapabilitySituation > ConfigureSituation > StopSituation > StartSituation > RequestSituation > DestroySituation > CreateSituation > DependencySituation > ConnectSituation > ReportSituation > OtherSituation > ------------------------------------------- > > I can not find any definition for the above value in "Appendix C. > Schemas" of MUWS part 2. > > I think the definition for the above value should exist in schema. > Am I wrong ? > > Regards, > > -- > Hiroyuki Masuda > E-Mail:masuda@soft.fujitsu.com > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

1 0

CIM JobState enumeration
by Christopher Smith 21 Jul '05

21 Jul '05

Hi all, First off ... apologies that I'll have to miss the call this morning. I'm still at O'Hare waiting for my 12:30am flight back to SF ... ETA at home at 3:30 or 4am. :-P I've looked into the operational states that the CIM model enumerates for BatchJob. They are actually inherited from the ConcreteJob object from the core model. Covers the basic states for the execution of the activity itself, but (probably as expected) does not cover the entire state + sub-state model that we have for an activity. Nice in that they do cover transitional states as well. Really just missing the file transfer sub-states. The states themselves: "JobState is an integer enumeration that indicates the " "operational state of a Job. It can also indicate " "transitions between these states, for example, 'Shutting " "Down' and 'Starting'. Following is a brief description of " "the states: \n" "New (2) indicates that the job has never been started. \n" "Starting (3) indicates that the job is moving from the " "'New', 'Suspended', or 'Service' states into the 'Running' " "state. \n" "Running (4) indicates that the Job is running. \n" "Suspended (5) indicates that the Job is stopped, but may be " "restarted in a seamless manner. \n" "Shutting Down (6) indicates the job is moving to a " "'Completed', 'Terminated', or 'Killed' state. \n" "Completed (7) indicates that the job has completed " "normally. \n" "Terminated (8) indicates that the job has been stopped by a " "'Terminate' state change request. The job and all its " "underlying processes are ended and may be restarted (this " "is job-specific) only as a new job. \n" "Killed (9) indicates that the job has been stopped by a " "'Kill' state change request. Underlying processes may have " "been left running and cleanup may be required to free up " "resources. \n" "Exception (10) indicates that the Job is in an abnormal " "state that may be indicative of an error condition. Actual " "status may be surfaced though job-specific objects. \n" "Service (11) indicates that the Job is in a vendor-specific " "state that supports problem discovery and/or resolution."), -- Chris

1 0

Re: [ogsa-wg] Re: [ogsa-rss-bof] OGSA RM teleconference -- where does resource modeling fits in?
by Mathias Dalheimer 18 Jul '05

18 Jul '05

Hi Fred, Hi all! Donal K. Fellows wrote: > Fred Maciel wrote: > >> First of all, sorry for the cross-posting -- this subject >> involves all three WGs. >> Since GGF14 there have been a lot of discussions on where resource >> modeling fits -- BES considered it out of scope but Andrew thinks it's >> not totally out; RSS is discussing whether it's in scope; and this was >> discussed in the OGSA-WG also. So, let's discuss this in the Resource Modeling >> design team teleconference (which is, in fact, the place to discuss this). > > Alas, the timing of the telecon is consistently impossible for me for > family reasons, and I'm pretty certain that Soonwook Hwang can't make > them either. (I'm not sure about Mathias Dalheimer.) I will be in the call tomorrow. I cannot make this nights OGSA-WG call. > However, so far we've discussed this within the RSS group by email and I > think we feel that from the point-of-view of the RSS, we will not be > saying very much at this stage. We do not wish to say that services [snip] We had an email discussion on the OGSA-RSS-BOF mailing list. You can see our argumentation in the archive: http://www-unix.gridforum.org/mail_archive/ogsa-rss-bof/2005/07/msg00008.ht… (and several follow-ups) To sum it up, we think it is an important discussion. It is out of scope for us, but we need to have an advanced resource model, especially - as Donal pointed out - when we want to deal with different user preferences etc. At the moment, I have the feeling that OGSA-RSS should focus on a more basic model in order to bootstrap its work. Therefore, the attributes in JSDL are our starting point. Of course, we will contribute our requirements when we identified them. -Mathias

1 0

[Fwd: BOUNCE ogsa-bes-wg@ggf.org: Non-member submission from ["Donal K. Fellows" <donal.k.fellows@manchester.ac.uk>]]
by Steven Newhouse 18 Jul '05

18 Jul '05

-- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Deputy Director, Open Middleware Infrastructure Institute (OMII) Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK

1 0