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

[Moreno Marzolla]

Dear Peter,

thank you very much for your feedback. Just some small comments on some 
of your points (we agree with the rest)

[...]

>>*    This is probably a “cosmetic” adjustment, but we believe that the
>>name of the “Release” operation makes sense only for reactivating jobs
>>from “Held” states; the transition from “Start Pending” and “Staging In”
>>could probably be called something like “Activate”.
> 
> 
> I don't think the ESI document says that the Release operation does
> this. It's only for releasing holds. Perhaps you are assuming an implied
> hold during "Start Pending" that isn't actually there? Is there a
> specific quote from the document that you think says this?

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

[...]

>>About the staging of files:
>>*    While it is clear that users might explicitly “push” files from
>>their storage space to the Grid while a job is in “Start Pending” state, it
>>is unclear how users might explicitly “pull” by hand resulting files from
>>the Grid after a job competed, and before everything gets cleaned up.
> 
> 
> We've run into this issue with WS-GRAM. One idea I proposed elsewhere is
> to have an extension to JSDL that specifies files you are interested in
> monitoring, and have RPs in the job interface that list URLs for those
> files so that you can, say, use GridFTP to pull them down. I'm on the
> wall whether this is appropriate for the ESI job interface or whether
> this should be a separate file monitoring interface. If you're wondering
> why I suggest RPs if you already know the file you want, this is because
> at least in WS-GRAM we allow for mapping of files to a GridFTP server
> that may not necessarily have the same file system view. In other words,
> the URL path part may not agree entirely with the path specified in
> JSDL.

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

[...]


>>*    It may be useful to provide an additional property (we may call
>>it “CommandList”) representing the list of all commands issued for a given
>>job.
> 
> 
> What do you mean by "command"? Typically there is only one executable,
> so if that's what you mean I don't quite follow you.

Well, we were using the term "command" to indicate the Job Interface 
Operations described in Section 5.2. Basically, for administrative 
purposes it could be useful if the sequence of operations performed on 
each job is logged and could be accessed in some way. But probably this 
operation is not strictly related to job submission and should be 
considered in a separate interface.

Regards,

Moreno.

-- 
Moreno Marzolla
INFN Sezione di Padova,    via Marzolo 8,   35100 PADOVA,  Italy
EMail: moreno.marzolla at pd.infn.it         Phone: +39 049 8277047
WWW  : http://www.pd.infn.it/~marzolla    Fax  : +39 049 8756233