[Pgi-wg] Pointers to interesting options in older BES specs

[Andrew Grimshaw]

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