Hi Craig, Quoting [Craig Lee] (Jan 25 2006):

All,

First of all, allow me to say that this is a good problem to have. The fact that the GFSG is considering whether SAGA should be one WG or an umbrella RG for multiple WGs means that people view it as important.

My personal opinion is that the SAGA-RG could continue as this umbrella organization, but to follow through with the original SAGA intent, an initial WG should be formed that is focused on _S_AGA.

I agree to that, that would be the simpliest way forward I guess. _if_ other WGs will form, and if the RG can be useful beyond its current scope is mainly a question of participation I guess...

To emphasize the _simple_ in SAGA I keep coming back to the analogy of "the six calls in MPI". Whether the current SAGA API is simple enough is separate discussion. In any case, the API should be (a) minimally complete, (b) easy for implementers to implement and (c) easy for new grid users to use.

Right. That should be (and I think is) the focus of our current API spec. Cheers, Andre.

As long as the umbrella SAGA-RG persists, it can consider issues of enhancing the API in various functional areas, e.g., data movement, and also establishing a common look-and-feel across them all. WGs could be spun-off as necessary.

Just my 2 cents.

--Craig

At 10:13 AM 1/24/2006, Andre Merzky wrote:

...

Dear group,

as you know, we are currently in transition from a GGF Research Group to a GGF Working Group, which will enable us to submit documents into the standardization track. The last action from our side was to submit the proposed WG charter to our Area Directors (Steven and Dieter), and wait for the last step in the process, the GFSG approval of that charter.

Below you find the answer we got from the GFSG. I know people will have strong opinions about that, both positive and negative (well, certainly I do anyway :-P ), so we would like to discuss the GFSG answer on this list. It would be favourable to come to a group internal conclusion, and a solid opinion, about the groups future before GGF16 - that means within the next two weeks.

Best regards,

your friendly group chairs ;-)

----- Forwarded message from Steven Newhouse -----

...

Date: Mon, 23 Jan 2006 07:38:45 +0000 From: Steven Newhouse To: Andre Merzky , Shantenu Jha , Tom Goodale CC: Dieter Kranzlmueller Subject: Re: SAGA - WG?

Dear Andre, Shantenu & Tom,

At the GFSG meeting last week, there was a general discussion as to how GFSG should/could steer the standards areas to increase the impact of GGF. One of the discussions related to the Applications area and how we (as Area Directors) could help to structure the activity to align work with activities in the Architecture (i.e. OGSA) area.

There was considerable interest from the rest of the GFSG in the SAGA activities and the potential uptake that the generation of stable client-side interfaces (and potentially command line tools that build on these interfaces) could provide. The GFSG saw SAGA-RG as an important step forward for grids being adopted by the wider community.

That's the good news!

We mentioned the pending SAGA-WG charter and that this was the next step to move things forward. Some concern was expressed about focus and broad scope. Especially as other domains would like to bring forward their own domains (data access, data movement, etc) for client side API standardisation.

One proposed solution to this is that SAGA-RG stays as it is. It is doing very valuable work collecting use cases, developing the strawman API that supports these use cases and discussing implementation issues through real experience. However, clearly there are elements within the strawman that are ready to move to the next level.

It is proposed that these aspects should be developed as standalone WG's starting with a common look and feel, and then picking up on (say) jobs & file movement to drive some domain specific applications of the common look and feel. The result would be an umbrella-RG (SAGA) with a set of coupled WGs for the different aspects.

So there are two ways forward - you have _our_ support which ever way _you_ choose to go forward.

If you go forward with then the current charter then you will need to be explicit as to which areas you will be doing (to allow space for other WG's to come forward), i.e. you need to define your API scope. Elements of the API will change at different rates and putting this all into one specification adds to its complexity. Small tightly focussed specifications have had much greater success within GGF. This may be something else to consider.

As a conclusion we hope that you will think about this great opportunity to take the responsibility for the bigger picture, and that you will adapt your plans accordingly from this feedback. We would certainly be available to support you in this quest. At the same time, it has also been agreed to continue the regular bit-flipping procedure with your charter, should you insist on your currently proposed approach.

Steven & Dieter -- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky@cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+

-- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky@cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+

I'll try and provide factual responses rather than opinions! BUt I expect I'll fail.

-- If the lack of focus is a concern (as has been expressed on this list and privately by some parts of the community), can that not be effectively addressed without spawning?

The current WG charter does not scope what it would explicitly do. If another group came along to do an API for X, the SAGA-WG _could_ say they it was within their scope. This is simple to fix by... Explicitly, scoping the proposed SAGA-WG activities would produce a list. A long list or a short list is in the eye of the beholder. But a question that would have to be answered why is this list of activities (API area) all part of one WG? The reason from SAGA is that there needs to be co-ordination - which I think there is general agreement about there is a need for this. The question IMHO is how to deliver this co-ordination. This appears to be the issue.

Also, spawning groups in itself isn't a guarantee of focus or simplicity. Spawning groups has a resultant high risk possibility that the spawned subgroups make each subsystem too exhaustive. Not that it can't happen with a single group, but just that the temptation is less acute. Similarly, might not each sub-group still end up losing focus (with the added overhead that fragmentation involves)?

A WG has a specific set of explicit deliverables/milestones that reigns it in. WG creep is monitored and controlled by the AD's and the GFSG.

-- In addition to concerns about the exact working relationship issues, a MAJOR fear that I have is that spawning groups might just be a symmetry-breaking event, i.e., where the common look-and-feel might be lost forever and will be irrecoverable in spite of an umbrella SAGA-RG.

Each WG has a remit to produce something. The 'umbrella' group looks at taking the output from the WG and ingesting it to ensure that it 'works'. The umbrella group has a lobbying obligation on the WG to make sure it fits. If the WG activity is well defined (informed form the RG activity) this should not be an issue.

SAGA is a meant to be a single consistent API. Might help to go back to the the MPI analogy. Did different parts of the MPI specification process evolve under distinct working groups? Or did the different 'sub-systems' evolve together? Why?

MPI (AFAIK) was put together by sub-groups (point 2 point, collective, etc.) working in isolation and then syncing up to be consistent.

-- EXACT working relationship between umbrella SAGA-RG and spawned SAGA-WGs?

For OGSA the spawned WGs are asked to join the OGSA telecons & the F2F to report on progress. There is a two way communication. A WG given an OGSA prefix has a 'responsibility' to engage in this. It should be (is) in their charter to do so... I believe.

-- Assuming SAGA goes with the spawning approach: What are the necessary conditions to spawn future groups? e.g., must each subsystem get its own WG? What are the sufficient conditions?

If its an identifiable scoped bit of work it should IMHO be in a WG.

-- At the risk of opening a whole new can-of-worms and that too a rather polemical one: Is the Go-henceforth-and-spawn suggestion a proxy to align SAGA more intimately with OGSA?

On a one-to-one level... no in my view. Its a model. The SAGA job submission activity might use the OGSA-BES and ByteIO services as part of one implementation, or WS-GRAM and RFT as part of another implementation.

What does, "SAGA being the public-face of OGSA" mean and imply?

SAGA being the higher-level API that an application developer might use to access service infrastructure, ONE implementation of that API would use the OGSA-* services.

Whereas I'm all for the alignment of SAGA and OGSA (even more if as has been said, "SAGA is the application area flagship of the GGF"), is there a premature and/or even an over emphasis on "aligning" SAGA and OGSA? If so, is this in the best interest of OGSA? SAGA? or GGF as a whole?

Alignment - OK. Tied exclusively too - not OK.

-- "Some concern was expressed about focus and broad scope. Especially as other domains would like to bring forward their own domains (data access, data movement, etc) for client side API standardisation."

I'm sure there is more to it than the following, but as a simpler first step, why can't we have more sanity checks with such domains e.g., http://www-unix.gridforum.org/mail_archive/saga-rg/2005/10/msg00017.html Doesn't approach appears to be working for DRMAA, GridRPC and GridCPR, if not data movement?

The RG spawning WG model would IMHO do that. These are all tightly scoped WGs.

-- In the case of a split opinion, how does the group make the final call?

AFAIK... the final call MUST go to the list. Rough consensus is the phrase... what that means in practice... has to be seen. Steven -- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Director, Open Middleware Infrastructure Institute-UK (OMII-UK) c/o Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK

I strongly vote for version 1! We had more than enough discussion. Either GFSG sticks to its word, or this the end. Namely, this is the end as GFSG in fact bores away its volunteers working on SAGA. To this end, GFSG almost succeeded already. If GFSG wants both an "oversight RG" and dedicated WG's it should come up with volunteers for doing all that work. The current group of (still) volunteers has done a splendid job on addressing real users' needs. I am afraid to say, as implementations are coming up these days, in combination with real users taking them up, SAGA will happen, with or without GGF labeling. My personal advice to my fellow colleagues in the standards council of GFSG is to grab this chance and build on the volunteer base it has, still. Constructive collaboration is what is needed, this sometimes comes with commitment and risk-taking by decision making, I am afraid. Thilo PS: This email solely expresses my personal opinion. On Fri, Feb 03, 2006 at 11:37:00AM +0100, Andre Merzky wrote:

X-Original-To: kielmann@localhost Delivered-To: kielmann@localhost.cs.vu.nl Delivered-To: grdfm-saga-rg-outgoing@mailbouncer.mcs.anl.gov X-Original-To: grdfm-saga-rg@mailbouncer.mcs.anl.gov Delivered-To: grdfm-saga-rg@mailbouncer.mcs.anl.gov Date: Fri, 3 Feb 2006 11:37:00 +0100 From: Andre Merzky To: Simple API for Grid Applications WG Cc: Dieter Kranzlmueller , Steven Newhouse , Shantenu Jha , Tom Goodale Subject: [saga-rg] Re: Fwd (s.newhouse@omii.ac.uk): Re: SAGA - WG? X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mailbouncer.mcs.anl.gov X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mailbouncer.mcs.anl.gov

Well, I can't make up my own mind on how to react on the GFSG discussion. Well, please allow me to post two reponses :-)

----------------------------------------------------------- Version one:

Well, I am quite furious to be honest. Why the heck did we sit down in Boston to discuss the SAGA scope with both GFSG members and OGSA/WSRF folx? We came to a conclusion there: SAGA scope is ok for now, they SHOULD be WG, go ahead. The issue was _settled_. Once more, since the issue has been settled about five times by now, since the formation of the group at GGF10 (just a reminder: ~50 votes for WG, 2 votes for RG).

So, here we are, 3 years later, and are STILL discussing the same issue over and over again, and all promises that the issue is closed are forgotten again. What a waste of time... :-(

The goal of the members of the SAGA group is AFAICS to define and standardize a well scoped, very simple, and highly needed API. Just that.

If there is a perceived need of the GFSG that GGF needs a public API facade, or of the OGSA folx that there is a need for a simple API on top of OGSA, then they probably should form a RG and define that!

I think its not the task of the GFSG to say: "you do good work, but please do something different." GGF does not work on requests, but is community driven. If other people would be interested in widening the scope of the SAGA-RG, they would show up in the meetings, submit use cases, author documents. Be active (hello OGSA?).

Those people who DO show up in our meetings (RPC, CPR, DRMAA, ByteIO, BES etc.) are satisfied with our scope (mostly we say: nice for you to come, but we have limited scope right now, your part comes later).

There are more than a few people scared away by the fact that SAGA is a research group, and still after three years, did not manage to become a WG, as was the plan in the first place!

Well, I think you got the point: in my opinion the decision to block the long priomsed flip into a WG is against the agreement we had with the GFSG, and not acceptable.

------------------------------------------------------------

------------------------------------------------------------ Version two:

Thinking positively, that is really good news. Well, what GFSG really says is: "Guys, you do a great job, we need more of this". Having the SAGA group scope broadening as an umbrella for community driven Grid APIs seems like a very good thing to do.

Several practical points come to my mind, though:

- we certainly don't want to delay the release of the current SAGA documents, in particular of the API spec, as the SAGA API is sorely needed NOW.

- The current API draft covers both functional (scope) and non functional (look and feel etc) aspwcts of the SAGA API. That defeats the approach proposed by the GFSG. However, I think that splitting the document NOW is not the way to solve this (we decided against that at last GGF).

Instead I would propose to continue our current work, with the declared goal to have the SAGA-API v.1 finalized ASAP, and then go ahead and start with a look-and-feel document afresh, based on our experience with the API. Alterantively, and given enough interest (see point below), both pathes can be performed in parallel.

- well, in order to do what the GFSG proposes we need more active people. And active meaning really active. It seems not enough to chat with other groups now and then: we need active participation of their group members in the SAGA document and API work.

It is not obvious to me how to achieve that, and if that need for active participation is perceived outside our group and the GFSG.

So I think the buttom line is: the way proposed by the GFSG offers a number of opportunities.

However, if we want to keep the deadlines attached to our current work, we would need to spawn a dedicated WG for these docs immediately (i.e. as of GGF16!) (possibly: iSAGA-WG - initial SAGA ;-P) That would basically move the current group to iSAGA-WG, with the scope defined by the current API spec.

------------------------------------------------------------

Hmm, the second version is probably the better one. Anyway, I am _really_ angry that promises by the GFSG are not kept.

Cheers, Andre.

Quoting [Andre Merzky] (Jan 24 2006):

...

Date: Tue, 24 Jan 2006 19:13:23 +0100 From: Andre Merzky To: Simple API for Grid Applications WG Subject: Fwd (s.newhouse@omii.ac.uk): Re: SAGA - WG?

Dear group,

as you know, we are currently in transition from a GGF Research Group to a GGF Working Group, which will enable us to submit documents into the standardization track. The last action from our side was to submit the proposed WG charter to our Area Directors (Steven and Dieter), and wait for the last step in the process, the GFSG approval of that charter.

Below you find the answer we got from the GFSG. I know people will have strong opinions about that, both positive and negative (well, certainly I do anyway :-P ), so we would like to discuss the GFSG answer on this list. It would be favourable to come to a group internal conclusion, and a solid opinion, about the groups future before GGF16 - that means within the next two weeks.

Best regards,

your friendly group chairs ;-)

----- Forwarded message from Steven Newhouse -----

...

Date: Mon, 23 Jan 2006 07:38:45 +0000 From: Steven Newhouse To: Andre Merzky , Shantenu Jha , Tom Goodale CC: Dieter Kranzlmueller Subject: Re: SAGA - WG?

Dear Andre, Shantenu & Tom,

At the GFSG meeting last week, there was a general discussion as to how GFSG should/could steer the standards areas to increase the impact of GGF. One of the discussions related to the Applications area and how we (as Area Directors) could help to structure the activity to align work with activities in the Architecture (i.e. OGSA) area.

There was considerable interest from the rest of the GFSG in the SAGA activities and the potential uptake that the generation of stable client-side interfaces (and potentially command line tools that build on these interfaces) could provide. The GFSG saw SAGA-RG as an important step forward for grids being adopted by the wider community.

That's the good news!

We mentioned the pending SAGA-WG charter and that this was the next step to move things forward. Some concern was expressed about focus and broad scope. Especially as other domains would like to bring forward their own domains (data access, data movement, etc) for client side API standardisation.

One proposed solution to this is that SAGA-RG stays as it is. It is doing very valuable work collecting use cases, developing the strawman API that supports these use cases and discussing implementation issues through real experience. However, clearly there are elements within the strawman that are ready to move to the next level.

It is proposed that these aspects should be developed as standalone WG's starting with a common look and feel, and then picking up on (say) jobs & file movement to drive some domain specific applications of the common look and feel. The result would be an umbrella-RG (SAGA) with a set of coupled WGs for the different aspects.

So there are two ways forward - you have _our_ support which ever way _you_ choose to go forward.

If you go forward with then the current charter then you will need to be explicit as to which areas you will be doing (to allow space for other WG's to come forward), i.e. you need to define your API scope. Elements of the API will change at different rates and putting this all into one specification adds to its complexity. Small tightly focussed specifications have had much greater success within GGF. This may be something else to consider.

As a conclusion we hope that you will think about this great opportunity to take the responsibility for the bigger picture, and that you will adapt your plans accordingly from this feedback. We would certainly be available to support you in this quest. At the same time, it has also been agreed to continue the regular bit-flipping procedure with your charter, should you insist on your currently proposed approach.

Steven & Dieter -- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky@cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+

-- Thilo Kielmann http://www.cs.vu.nl/~kielmann/