[ogsa-bes-wg] Additional Input into BES w.r.t ESI document

[Karl Czajkowski]

On May 19, Moreno Marzolla modulated:
...
> From section 3.2.1: "The job will remain in Pending until it receives a 
> Release event from the Job Release operation, which will move it to 
> Running". (I think that the "Pending" state mentioned here is the state 
> labeled as "Start Pending" on Figure 2). From this we where assuming an 
> implicit hold. If this is not the case, is the transition Pending -> 
> Staging In instantaneous?
> I think that it would be useful to provide a complete description of 
> states and transitions in section 3.2.1 of the document (that is, 
> expanding Table 1).
> 

I would hope this is simply a text versioning issue, and that any of
the hold states would be explicitly enabled/disabled by job document
content so that the transitions can be instant or blocked on client
"release" actions.


> What we had in mind was simply to make the transition(s) from states 
> "Executing" -> "Staging Out" -> "Cleaning Up" not instantaneous, so that 
> files do not get immediately purged.

Yes, we do the same thing as you are thinking in WS-GRAM through the
use of a hold state between the staging out and cleaning up steps.
The other issue Peter is highlighting is something we had to address
in WS-GRAM: the namespaces of the local job filesystem and the data
access interface may not be identical, so some sort of mapping needs
to be exported.

In our case, standard GridFTP is the data access (monitoring)
interface, so we had to expose the mapping for the client to convert a
job output file URI into a GridFTP URL.  With a web-service based file
access interface, this mapping could probably be wrapped up so that
the data access remains relative to the job's output file namespace?


> Anyway, according to the current JSDL specification, it is possible to 
> specify DataStaging elements with the "DeleteOnTermination" sub-element 
> set to False, meaning that a given file should NOT be deleted after the 
> job terminates. In this case, even if the transitions "Executing" -> 
> "Staging Out" -> "Cleaning Up" are instantaneous, the user might later 
> access files for which the "DeleteOnTermination" flag was set to false.
> 

Personally, I think that is insufficient in JSDL.  You want to be able
to pause for safe interlock of 3rd-party data monitoring, but still be
able to clean up without having either of:

   -- client obligation to remove files

   -- unbounded lifetime of temporary job files after job exits

There are jobs where cleanup is not desired, but I do not think that
should be considered the same as this output monitoring and
synchronization...


karl

-- 
Karl Czajkowski
karlcz at univa.com