[ogsa-bes-wg] Proposed changes to Spec.

[Ian Foster]

Andrew:

We should ask the OGSA-WG to speak definitively on the first issue, as 
there seems to be confusion among participants as to what the policy means.

Regarding OGSA-BES's use of WS-Name: I appreciate the information on the 
decision procedure.

More generally, I guess this exchange reflects a common tension between the 
relative importance of the views of "insiders" vs. "outsiders" in GGF WGs. 
I know that quite a few people (myself included) started off wanting to 
engage as insiders in OGSA-BES, but after various unsatisfactory 
interactions (e.g., discussions like this one, where the response to a 
concern is to be told that it will be disregarded), ended up becoming 
outsiders. The OGSA-BES is of course free to work as it wants, but 
excluding the views of so many people also greatly reduces the likelihood 
that whatever specifications OGSA-BES produces will be widely adopted.

I don't understand the discussion of events: I didn't speak to eventing in 
my email, but about the right way of specifying the activities to which an 
operation should apply.

Regards,

Ian.


At 01:05 PM 10/26/2005 -0400, Andrew Grimshaw wrote:

>Ian,
>
>My understanding of the OGSA policy is that OGSA does not mandate WS-Names 
>& instead it encourages them WHERE THEY ARE APPROPRIATE. That decision is 
>up to individual working groups, and perhaps a design team working on a 
>profile. The policy, in my mind, is NOT that WS-Names may not be mandated 
>by OGSA specifications.
>
>
>
>In the case of OGSA-BES, at the last GGF in Boston the working group 
>discussed at great length the pros and cons of WS-Names, opaque EPRs, and 
>abstract names (i.e., uris with a few properties). The overwhelming 
>majority preferred WS-Names (an explicit, comparable return value) (8 to 
>2). A further discussion was held as to whether the WS-Names should have 
>both abstract names AND resolvers, and the vote was 4 to 1 for having a 
>resolver, with many people indifferent.
>
>
>
>Thus, OGSA-BES will have* WS-Names as return values and input parameters.
>
>
>
>We also discussed eventingat some length. I have not yet typed in my 
>notes, the three high order bits were:
>
>1)       The container is the right place to emit the events
>
>2)       Clients must explicitly subscribe to events (use filtering from 
>the container, not specific registration& Im not sure what that means, I 
>think we will need to discuss this in a call and remind me.)
>
>3)       Events are state transitions of the activities
>
>Andrew
>
>
>
>*Of course the document still has to go into public comment, get revised, 
>and hopefully some day be approved by the GFSG. What is really in the 
>document may change between now and then.
>
>
>
>----------
>From: owner-ogsa-bes-wg at ggf.org [mailto:owner-ogsa-bes-wg at ggf.org] On 
>Behalf Of Ian Foster
>Sent: Wednesday, October 26, 2005 11:40 AM
>To: Darren Pulsipher; ogsa-bes-wg at ggf.org
>Subject: Re: [ogsa-bes-wg] Proposed changes to Spec.
>
>
>
>Darren:
>
>I would like to argue against your proposed operations on the grounds of 
>fragility and scalability.  Your operation definitions require that a 
>client keep track of the set of activities to be monitored and controlled. 
>That's a big burden to place on the client.
>
>I suggest (as we have also suggested in earlier communications to BES-WG) 
>that we should instead allow the user to specify a set of activities that 
>are to be monitored or controlled in terms of their properties, not names. 
>E.g., "activities that belong to me", "activities that involve executable 
>Foo", "activities that have been running for over 2 hours."
>
>A natural way of modeling this is to represent the set of activities 
>associated with your jobs as a WS-ServiceGroup Service Group, and then use 
>queries on the service group to specify the activities to which an 
>operation applies.
>
>Regards -- Ian.
>
>PS: As noted in previous emails and conversations, I also believe that the 
>use of WS-Names rather than vanilla EPRs is inappropriate. I also believe 
>that it is inconsistent with the OGSA policy that WS-Names cannot be 
>mandated in OGSA-related specifications.
>
>
>
>At 08:52 AM 10/26/2005 -0600, Darren Pulsipher wrote:
>
>I have spent some considerable time with the document.
>I know far more than I planned, but it was good time spent.
>I think we should discuss these items in our meeting on Thursday.
>I have posted some changes to the document but would like to discuss
>these items before I make these changes to them.
>
>There are some fundamental problems/questions that we need to resolve.
>
>1. How do we resume from where we left off. There is no Resume anymore
>so we are putting the responsibility to the submitter or controller to
>keep track of states. We can only use RequestActivityStateChanges to
>suspend something and if I want to suspend 1000s of activities that
>means I would need to first do a GetActivityState save the states and
>then call RequestActivityStateChanges without any of the activities
>changing state. That is not going to happen. So I propose we do the
>following:
>- Add the following interfaces:
>SuspendActivites(WS-Name[] activityIdentifiers)
>ResumeActivities(WS-Name[] activityIdentifiers)
>
>Or we add one interface
>PerformOnActivites("Suspend" | "Resume", WS-Name[] activityIdentifiers)
>
>2. Another problem is how do we terminate an activity. The States that
>are available are "Terminated" and "ShuttingDown". According to the
>state net the activity is moved to the "ShuttingDown" and then to
>"Terminated" so requesting RequestActivityStateChanges for activities
>with "ShuttingDown" means it should move to the ShuttingDown state but
>it will move the activities to the "Terminated" state. This can be very
>confusing. So I suggest we add another interface.
>- Add the following interface:
>TerminateActivities(WS-Name[] activityIdentifiers)
>
>Or add another possible argument to the interface.
>PerformOnActivites("Suspend" | "Resume" | "Terminate", WS-Name[]
>activityIdentifiers)
>
>3. Another question that is not clear in the spec is if an action
>(staging in or staging out) moves into an exception state does that mean
>that the activity moves into the exception state right away or does it
>mean that it ever moves into the exception state. Does it mean that if
>one of the actions moves into an exception state that all other actions
>are halted and moved to the exception state and then the activity?
>- I proposed that actions state have no impact on the activity state. If
>an action has an exception or is terminated then it should not have any
>impact on the activity what so every.
>
>4. Another not so important change but it might help clarify some
>confusion and allow for extendibility later on would be to get rid of
>the "ExecutionPending" and "ExecutionComplete" and make the "Running"
>state a composite state like the "StagingIn" and "StagingOut" states.
>This will give the ability to handle complex multiple application
>execution definitions that the JSDL group is looking at for the next rev
>of the Job Definition. This will allow for multiple Application actions.
>This is not workflow. Nor should it be considered the start of workflow.
>This just allows for extendibility easily.
>
>
>Darren Pulsipher
>
>_______________________________________________________________
>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

_______________________________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-bes-wg/attachments/20051026/4d850bdb/attachment.htm