- ogsa-wg - lists.ogf.org

[ogsa-wg | Basic Profile - 1222] Profile scope Appendix A (Reference Specs)
by Sourceforge Tracker Monitor 28 Jan '05

28 Jan '05

A new artifact has been added: 1222 Submitted by: Tom Maguire Submitted date: 2005-01-28 13:30:58 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1222&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1222&group_id…) Summary: Profile scope Appendix A (Reference Specs) Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1222 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Last Modified: 2005-01-28 13:30:58 Submitted By: Tom Maguire Submit Date: 2005-01-28 13:30:58 Assigned To: &lt;None&gt; File(s): <None> Description: Include by reference all of the reference specs from WS-I BP 1.1. Are there any others that need to be included?? View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

SetResourceProperty and WSDM
by Fred Maciel 28 Jan '05

28 Jan '05

Hi, > Should make WSDM aware about the 'set resource property' issue. > (Provided wants WSDM to be 'aligned' with the OGSA profile.) > Fred is the OGSA-WSDM liaison. I raised the issue at the WSDM teleconference earlier today. First of all, from the MUWS part 2 spec: "Specifically, the interface MUST include the GetResourceProperty operation defined by [WS-RP] and MAY include the GetMultipleProperties, SetResourceProperties and QueryResourceProperties operations." So, SetResourceProperties is not mandatory in WSDM. In the configuration capability, it says that: "WS- ResourceProperties SetResourceProperty operation MAY be used to change a configuration value." Again, not mandatory. So, whether SetResourceProperties is a MUST or not will depend on the specific mapping from MUWS to a given domain. And in the teleconference I was given a very good example, which is CIM. It is quite natural to do setup on resources (configure, control, etc.) using SetResourceProperties (that would be functionality similar to SetProperty, ModifyInstance, etc. in WBEM). This single operaton should be enough. Conversely, if we don't use it, we will need a *zillion* different operations (one for each and every property in every class of the model?), which will be a pain. So, no problems for now, but we (OGSA and WSDM) will definitely need to keep in sync. And I'd say that their input above is valuable. Regards, Fred Maciel. P.S. - For the WBEM operations, see: http://www.wbemsolutions.com/tutorials/CIM/wbem-operations.html

1 0

WSDM-related materials
by Fred Maciel 27 Jan '05

27 Jan '05

Hi, - Here is the URLs for the WSDM demo on the blackberry. http://www.oasis-open.org/committees/download.php/11086/WSDMDemo.010805.ppt - The presentation on the WSDM mapping to CIM, which was created by IBM, HP, CA and Cisco, is on the WSDM mailing list, but only available to TC members. Sigh... (They will publish the document -- they are working on the IP issues now). See ya, Fred Maciel.

1 0

EMS Teleconference minutes - 17 January 2005
by Andreas Savva 26 Jan '05

26 Jan '05

EMS teleconference minutes from Jan 17. Url: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-ems-20050117/… (Sorry for the delay. I wasn't actually asked to take minutes but Hiro wouldn't let me off the hook.) -- Andreas Savva OGSA EMS Teleconference - 17 January 2005 ========================================= * Participants Ravi Subramaniam (Intel) Dave Snelling (Fujitsu) Andreas Savva (Fujitsu) Mark Morgan (UVa) Tom Maguire (IBM) Fred Maciel (Hitachi) Hiro Kishimoto (Fujitsu) Andrew Grimshaw (UVa) Ian Foster (ANL) Dave Berry (UK NeSC) * General discussion - Agreed that the EMS space lacks concrete specs. - Initial focus on capabilities to guide effort in exploring the area---it seems premature to do an EM profile. - JSDL and WS-Agreement do seem to have some momentum behind them. But these pieces do not offer sufficient coverage to do a profile. - (Clarification that a Profile's purpose is interoperability.) - Proposal for discussing what a reasonable aim is---a gap analysis of sorts. - Agreed to the following: 1. Document the process of defining what we want to do a) Look at what there is in EMS (OGSA version 1.0) b) Subset it c) Union with outside specs d) Decide where new groups are needed (to fill the gaps) - Goal: short-term (candidate) profile that can produce something demonstrable - Clarification that "short term" means "year's end" - *Candidate* profile since it only has to identify the activity leading to a spec. - Detail concepts first? Might not finish until the profile is done. - Profile to cover as a minimum a "Hello world" level of functionality. 2. Look at what is there already in the EMS draft and what is the minimum subset that can be done as a first step. (To do.) 3. What is basic functionality? - Talk to a service/container/resource to start up something - If the executable is there just pass a path to it, or get it to the machine first---in some simple manner (no full-blown deployment configuration; just a data transfer) - (Ian) GT4 as an example that covers such simple functionality - (Dave) Unicore/unigrids as another example - Other efforts might offer input here, e.g., EGEE, etc - These examples might look very similar but their are subtle differences Proposal: Do a BoF on basic EM functionality. - The two projects above are willing to put forward complete WSDL specifications of relevant port types. This is important because they can be used as the starting point for standardization. - Should the entry point be the existence of WSDL specs? - Various opinions, but the rough consensus towards 'yes.' - Would like to also get Condor on-board (but need WSDL) - Condor has a WSDL sub-project: "Condor meets Soap" aka 'birdbath' - (DRMAA as an example that has an abstract definition but looks like a lot of work to put in WSDL) - Shared understanding that we can look at existing effors, invite groups to join, but cannot force participation in such a standards effort. And cannot just stop and wait. - Is there a preference to start from scratch? - Or, make sure that other efforts are also reviewed? - Consensus that it is easier to start from existing examples Action: Ian will send a pointer to the list describing the GRAM interfaces (Done) - Agreed that background work to review the various material is needed first. - For BoF need to also leave door open for people who may be proposing solutions not based on WSRF (e.g., OMII, etc) - The BoF is in addition to the profile work; fill the perceived gap in the EM space while the profile defines interoperability. - Clarified that the BoF is specifically on the submission interface; not the whole EMS space. - JSDL and WS-Agreement might be pieces used in the Profile. - (And might need more bofs for other pieces as gaps become more visible) - Forming such a group motivated/became obvious due to the work in EMS - Need/desire to make sure that it fits in OGSA-EMS - And that can only be done through participating in the proposed new group. Action: Work on drafting the charter for the BoF - Obviously do not to call it EMS; it is focused on a small subset: 'submission API' - This is not technical (design) work. - If the process is - (simple definition/provisioning), instantiation, execution, management - then BoF preparation is to decide what the minimal subset is. - Andrew and Dave volunteered to do a draft (initial proposal) of what is the important basic functionality and scope it as part of F preparation (initial proposal) (partly done) Additional actions: Action: Dave B to send WS-Agreement and DAIS link to the list. Action: Ravi volunteered to do a map of existing specs; what is there, now * Next EMS call: Jan 26 (to include BoF discussion) * OGSA EMS version 1.0 revision update - Andreas did a revision of the EMS section in OGSA version 1.0, to address some lingering issues: removing the term 'task' and modifying the explanation for 'Job' - Key changes: - Replace 'task' with generic 'unit of work' or delete as appropriate - Change order in definition of 'Job' so that the statement 'Job is a resource' comes later. Also remove too concrete statements (job is not workflow) that raised many comments at GGF12. Action: Andreas will fold in changes to next (final) draft and review in a subsequent call. (Done)

1 0

CMM document -- final call
by Fred Maciel 26 Jan '05

26 Jan '05

To: CMM-WG and OGSA-WG Hi, Here is version 28 of the CMM document, and a spreadsheet with the changes. (The main changes from last version were defining acronyms and correcting the references). Hopefully I will submit this one to the GGF editor. If you find any problems, please send to the CMM-WG and/or OGSA-WG mailing lists within one week. Thanks in advance, Fred Maciel.

1 0

Proposed agenda for Jan. 26th call
by Hiro Kishimoto 25 Jan '05

25 Jan '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on January 26th Wednesday from 5pm to 7pm (CST). Dial-in numbers for Wednesday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0126 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (10 min) Note taker assignment Roll call Telecon minutes approval * Nov 23rd and Jan 24th calls: (maybe Jan 17th too) http://tinyurl.com/5fxfd/minutes-ems-20041123/ https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050124/en/1 Agenda bashing 2) Feb F2F meeting and GGF13 update (10 min) Andrew will submit F2F logistics if available. 3) Basic profile discussion (40 min) Tom will provide next version of BP before the call. 4) Basic EM profile discussion (30 min) - Catalog applicable standards - Review known standards wrt to the architecture - Identify initial set 5) Simple job API WG BoF discussion (30 min) Scoping for Job Creation and Management. Plan for GGF13 BoF. 6) Wrap up (10 min) AOB Jan. 31 (5pm-7pm CDT) OGSA roadmap discussion Feb. 2 (10am-noon CDT) Data design team Feb. 2 (5pm-7pm CDT) <TBD> ---- Hiro Kishimoto

1 0

Teleconference minutes - Jan. 24, 2005
by Andreas Savva 25 Jan '05

25 Jan '05

Minutes attached. Gridforge link: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050124/en/1 -- Andreas Savva Fujitsu Laboratories Ltd.

1 0

Re: [ogsa-wg] OGSA-EMS Meeting Agenda (2005-01-17)
by Ian Foster 24 Jan '05

24 Jan '05

Ravi: You've asked to pointers to relevant standards, but to first order there aren't any. That does make me wonder whether it is even possible to have a meaningful conversation about an EMS interoperability profile at this time, given that a profile is supposed to document an established use of established standards. I believe that the interfaces developed by the Globus team for GT4 GRAM are relevant to an EMS discussion, in that they represent the result of an intensive effort to develop WSRF-based job management interfaces. Documentation is at: http://www-unix.globus.org/toolkit/docs/development/3.9.4/execution/wsgram/ The concepts are described here: http://www-unix.globus.org/toolkit/docs/development/3.9.4/execution/key/WS_… And some of the interfaces here: http://www-unix.globus.org/toolkit/docs/development/3.9.4/execution/wsgram/… Regards, Ian. At 11:14 PM 1/14/2005 -0800, Subramaniam, Ravi wrote: >Hi, > > > >Here is the agenda for this Mondays teleconference. As agreed at the last >F2F we will be focusing on developing an EMS interoperability profile. We >will use the Draft Profile template (Tom, Dave) as a reference (attached >for you convenience). We encourage persons who are active in relevant GGF >and other standard organization WG and people who are very familiar with >relevant standards to attend these meetings to provide the right and >informed perspectives and inputs. > > > >If you would be willing to educate the rest of the participants on one or >more applicable standards that you are very familiar with please let me >know and I can schedule some time. These would be brief overviews that >would lead to more detailed discussions in future as we narrow on the >appropriate set. > >Please send me pointers to definitive documentation on any standards that >you feel should be part of the EMS profile. I will compile these as >references for those who need to delve deeper. > > > >Dial-In > > > >Date: January 17th, 2005 (Monday) > >Time: 5 7 PM (CST) > > > >The dial-in number for Monday > > Free: +1-866-639-4741 > > Toll: +1-574-935-6703 > > PIN: 8980700 > > > >Screen share service will be provided. > > URL: <http://ogsa.glance.net/>http://ogsa.glance.net > > Session key: 0117 > > > >See more explanation: > ><http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html>http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html > > > >Agenda: > > > * Roll Call (5 mins) > * Agenda Bashing (10 mins) > * Ratification of previous minutes (5 mins) > * EMS profile discussion (tentative) (90 mins) > * Catalog applicable standards > * Review known standards wrt to the architecture > * Identify initial set > * Opens and wrap up. (10 mins) > > > > > >Thanks! > > > >Ravi _______________________________________________________________ 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

6 6

Data: Proposed agenda for Wednesday 26th January (also potential change of time)
by Dave Berry 24 Jan '05

24 Jan '05

Dear all, Here is a proposed agenda for the data telcon on Wednesday January 26th, which will be at the usual time of 8.00am (PST) / 11.00am EST / 4.00pm (GMT) / 5.00 pm (CET). We have been asked to consider a slightly earlier time slot. Can people make half-an-hour earlier? UK Dial In: 0845 245 0224 USA Freephone: 1866 838 0046 International Dial In: +44 1452 542309 PIN: 632 065 (Reference 2527179) 1) Early discussion (5 min) Note taker assignment Roll call Minutes approval (attached) - https://forge.gridforum.org/projects/ogsa-wg/document/Minutes_19th_Janua ry_2005/en/1 Agenda bashing 2) Update on outstanding actions (10 min) - Simon to mail the list about different types of metadata (data resource vs. service). - Dave to check with Dave Snelling when Basic Profile is ready for review. - Discuss time slot in e-mail. 3) Architecture issues (40 min) - I have been working on the straw man document, with input from a small group of people. This is beginning to take a coherent shape and I hope to distribute it more widely after next week's London meeting. The telcons are useful in resolving issues that arise while writing this straw man. - Is data transfer a service? - Are we transferring data (bits) or information (with some semantic content)? - Can we use the BasicFiles interface for both data and information? - How do we specify data types? - Other issues - Do we have volunteers to write subsections of the document? 5) Wrap up (5 min) AOB DONM - F2F in London, Feb 2nd. Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

RE: [ogsa-wg] FW: Issue #1 proposed resolution
by Ian Foster 24 Jan '05

24 Jan '05

I think the technical term is "carefully architected set of specifications" not "house of cards" (-: Regards -- Ian. At 05:10 PM 1/21/2005 +0000, Djaoui, A (Abdeslem) wrote: >Well, it probably doesn't, because WSRF is now decoupled from WS-Addressing >through the definition of the "abstract" resource Access Pattern, which >defines different embodiments for different ways of accessing state. > > >Abdeslem >/////////////// > >-----Original Message----- >From: Stephen Pickles [mailto:stephen.pickles@manchester.ac.uk] >Sent: 21 January 2005 17:05 >To: 'Djaoui, A (Abdeslem)'; 'OGSA-WG' >Subject: RE: [ogsa-wg] FW: Issue #1 proposed resolution > >Doesn't this make the whole house of cards (WSRF and OGSA) >come tumbling down? > >Please tell me I'm wrong! > >Stephen > > > -----Original Message----- > > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > > Behalf Of Djaoui, A (Abdeslem) > > Sent: 21 January 2005 09:47 > > To: 'OGSA-WG' > > Subject: [ogsa-wg] FW: Issue #1 proposed resolution > > > > > > Just in case you have not seen this, It appears RefProps will > > be removed > > from EPR's. Something we should discuss. > > > > Abdeslem > > ///////////////// > > > > -----Original Message----- > > From: public-ws-addressing-request(a)w3.org > > [mailto:public-ws-addressing-request@w3.org]On Behalf Of Ugo Corda > > Sent: 20 January 2005 01:33 > > To: Mark Little; Mark Baker > > Cc: public-ws-addressing(a)w3.org > > Subject: RE: Issue #1 proposed resolution > > > > > > > > Mark and Mark, > > It looks like RefProps are gone as of yesterday: see > > http://www.w3.org/2002/ws/addr/wd-issues/#i001 . > > > > Ugo > > > > > -----Original Message----- > > > From: public-ws-addressing-request(a)w3.org > > > [mailto:public-ws-addressing-request@w3.org] On Behalf Of > > Mark Little > > > Sent: Wednesday, January 19, 2005 5:26 PM > > > To: Mark Baker > > > Cc: public-ws-addressing(a)w3.org > > > Subject: Re: Issue #1 proposed resolution > > > > > > > > > > > > Mark, I have a distinct dislike for RefProps/RefParams, as > > > you're aware. However, putting my pragmatic hat on for a > > > moment, I don't see them vanishing in this release of the > > > specification. That doesn't prevent us from debating their > > > utility (or lack thereof), but I suspect it would be better > > > to take it off this mailing list if we're to try to maintain > > > the timeline that was proposed by the submitters and agreed > > > upon by the members of the group. Who knows, there may be a > > > change in a subsequent release? > > > > > > Also, I'm not sure why you moved my text around, but it could > > > change the context of what was originally intended. I didn't > > > mention the word "identification" at all in the proposed > > text I said. > > > > > > Mark. > > > > > > ---- > > > Mark Little, > > > Chief Architect, > > > Arjuna Technologies Ltd. > > > > > > www.arjuna.com > > > > > > > > > ----- Original Message ----- > > > From: "Mark Baker" <distobj(a)acm.org> > > > To: "Mark Little" <mark.little(a)arjuna.com> > > > Cc: <public-ws-addressing(a)w3.org> > > > Sent: Thursday, January 20, 2005 12:26 AM > > > Subject: Re: Issue #1 proposed resolution > > > > > > > > > > Mark, > > > > > > > > On Wed, Jan 19, 2005 at 10:41:53PM -0000, Mark Little wrote: > > > > > I think the pragmatic view on RefProps/RefParams has to > > > be that they > > > will > > > > > stay (rightly or wrongly, there are implementations and > > > > > specifications > > > out > > > > > there that now rely on them). > > > > > > > > This is a new spec we're working on, no? Those > > implementations can > > > > continue to depend upon whatever version of the spec they > > currently > > > > depend upon. Nothing we do here can break them, AFAICT. > > > > > > > > > I agree that the term "identifier" can be > > > > > contentious. However, so can the term "state". How about just > > > > > calling it/them "additional information that referencing > > > > > specifications [aka > > > using > > > > > specifications] or implementations need in order to ultimately > > > > > address > > > the > > > > > endpoint service"? > > > > > > > > >From my POV, there appears to be agreement to removing > > the part of > > > > >the > > > > spec that talks about using RefProps for identification. > > > Adding "in > > > > order to ultimately address" back in would be akin to > > undoing that > > > > change. The point of the change, as I see it, is to get > > > identifying > > > > information out of the RefPs, and into the URI, and I > > > consider that an > > > > enormous improvement over the WS-A submission. > > > > > > > > > That way we're not saying *what* goes in there, only > > > > > *why*. > > > > > > > > IMO, identification is a "what". > > > > > > > > Mark. > > > > -- > > > > Mark Baker. Ottawa, Ontario, CANADA. > > > http://www.markbaker.ca > > > > > > > > > > > > > > > > > _______________________________________________________________ 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

6 6