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

[Ian Foster]

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