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

draft-ggf-ogsa-bes-spec-v5
by Steven Newhouse 09 Aug '05

09 Aug '05

Further change tracked revsion to the changes Andrew made in the call. Ignoring white space alterations: * Extra arrow on the action state change diagram for Not Started to Active change. * Revision to the execution action with the 'Execution State' being reflected in the top-level state diagram. * Moving the authorisation issue to the security section. Discussion will continue from section 3.3 on this Thursday's call. 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

3 7

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

OGSA RM teleconference -- where does resource modeling fits in?
by Fred Maciel 15 Jul '05

15 Jul '05

Hi, 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). Oh, yes, part of this was supposed to be discussed in the RM teleconference this week, but only I and Ellen could come... Here are the details: Date: Tuesday, July 19th, at the following times: - 11:00-12:00 US Pacific (GMT - 7) - 12:00-13:00 US Mountain (GMT - 6) - 13:00-14:00 US Central (GMT - 5) - 14:00-15:00 US Eastern (GMT - 4) - 18:00-19:00 GMT - 19:00-20:00 UK (GMT + 1) - 20:00-21:00 Central Europe (GMT + 2) - 03:00-04:00 Japan (GMT + 9, following day) -- sorry. Dial-in: Toll Free: (888) 422-7120 Int'l Access: (608) 250-0194 Participant code: 693305 If screen sharing is needed, let's use Glance: URL: http://ogsa.glance.net Session key: 0719 Explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html See you there, Fred Maciel Hitachi America R&D

1 0