What is the process for addressing the concern that I raised
on 10/16 (enclosed below)?
I can of course wait for the public comment period to express concerns
about the specification, but I am trying to engage.
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.
At 02:44 PM 11/16/2005 -0500, Andrew Grimshaw wrote:
All,
Many people are at SC this week and
cannot make the telecon. As next Thursday is Thanksgiving here in the US
(one of the top two holidays) I propose that we skip next weeks telecon
as well, and schedule our next telecom for Thursday, December 1, at the
usual time.
The primary issue on the table is the
use of WS-Names in BES. There is a proposal under discussion in the
OGSA-WG to prohibit mandatory use of WS-Names in ANY OGSA specification.
That would impact BES in that the current specification requires the use
of WS-Names as return types and parameters to many of the
operations.
This has generated a proposal (during
discussions) that if WS-Names cannot be mandated, that BES revert to the
original draft use of AbstractNames (i.e. strings) as the parameters and
return values of the functions.
Another issue that needs discussion is
some changes to the document itself. As Mark Morgan has begun
implementing a prototype of the draft specification several
under-specified, or incompletely specified issues have come up. In
separate email he discussed some of those. We will need to take actions
(yea/nea) on some of his choices.
Andrew Grimshaw
Professor of Computer Science
University of Virginia
434-982-2204
grimshaw@cs.virginia.edu
_______________________________________________________________
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