Fwd: RE: [ogsa-bes-wg] Proposed changes to Spec.

[Ian Foster]

Hi,

I wanted to follow up on my email below. There wasn't any response to the 
concern I raised concerning the proposed operations, and I think it is an 
important issue that should be discussed.

I realize that the BES management might reply that I need to join the phone 
calls, but that isn't easy for me, and I think that we should be able to 
discuss issues on the email list also.

Regards,

Ian.

>>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.
>>
>>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

_______________________________________________________________
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/20051108/2b0692f4/attachment.htm