[Pgi-wg] Pointers to interesting options in older BES specs
Andrew Grimshaw
grimshaw at virginia.edu
Fri Apr 17 09:48:41 CDT 2009
All,
In v32 of the BES there were two things that did not make the final cut:
BES_Activity porttype and particular sub-state models for staging, suspend
resume. Further the base state model had an initial pending state, and there
were portypes to trigger a state change to running.
BES_Activity porttype. P. 6, 22
The idea was that the EPR returned from create activity would support the
BES_ACTIVITY porttype. What ended up in the document was pretty weak. The
idea is that there would be additional porttypes to interact with the
running job, change state, etc.
For example, there might be a portype that returned an EPR to an RNS
directory that proxied access to the "session directory" of the running job.
Clients could then read/write files using the ByteIO functions.
For example, we are implementing the activity EPR to implement the RNS
porttype, with several pseudo directories and files under it, one for the
"session" directory that can then be read and written to directly,
Activity
Session_dir
Files
Stderr - a streamable byteio
Stdout - a streamable byteio
Stdin - a streamable byteio
Status - a byteio file that can be read
Control-file - a byteio that can be used to send signals to the
job
Proc-mem - a byteio file that provides access to the memory of
sequential processes, so that debuggers can be attached
If you wanted other file transfer mechanisms, then put the URI's in
degenerate EPR's and put them in the RNS directory with some other name.
As an aside, when you combine this with a FUSE driver (as we have done),
grid un-aware clients can directly manipulate these files and directories
from unix programs and shell scripts as standard files.
As to state models. See pages 8-13, section 4.1
I recommend minimal changes to the base state model - adding the pending and
some way to kick it to running. That way the client could state data in
during the pending stage. Also, we would need a minor mod to the JSDL to
indicate whether we want the job to "start" in pending or running.
While we're on that topic, at one stage (no pun intended) BES had the
ability to send notifications to clients when jobs changed state. It was
ultimately removed because of a MS/IBM-Globus battle over which notification
scheme to use. I think we might want to consider putting it back in.
A
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/pgi-wg/attachments/20090417/4c04182b/attachment.html
More information about the Pgi-wg
mailing list