
Outside the SAGA use cases, we got feedback from some medical people about the job API. Open questions in the discussion have been: - When are files created by a job cleaned up? - Can we call clean_up? - Can specify files to clean up, if default is to leave them be? Their concern is mostly privacy: they want to ensure that no data a job worked on are left behind. Does anybody have insight into the semantics of the BES clean-up stage, or of other job managers? Do other people also see the need for explicit clean-up? If not (e.g. no answer in one week), I would leave that issue for later consideration, as we get more specific use cases in that respect. Cheers, Andre. -- "So much time, so little to do..." -- Garfield

Ultimately the job of cleaning up is left to the implementation, but it does needs hints through the job description. I believe that JSDL has a richer set of semantics for describing this kind of stuff than we currently support through SAGA. Should we just map the JSDL descriptions of file operations through to SAGA, or consider a minimal subset. This kind of cleanup is most often (practically) done using post execution scripts and the like within the queuing system, if not done explicitly by the job script itself, rather than supported as an operation of a resource manager. I don't know about brokering middleware and the like. -- Chris On 21/2/06 09:41, "Andre Merzky" <andre@merzky.net> wrote:
Outside the SAGA use cases, we got feedback from some medical people about the job API. Open questions in the discussion have been:
- When are files created by a job cleaned up? - Can we call clean_up? - Can specify files to clean up, if default is to leave them be?
Their concern is mostly privacy: they want to ensure that no data a job worked on are left behind.
Does anybody have insight into the semantics of the BES clean-up stage, or of other job managers? Do other people also see the need for explicit clean-up?
If not (e.g. no answer in one week), I would leave that issue for later consideration, as we get more specific use cases in that respect.
Cheers, Andre.
participants (2)
-
Andre Merzky
-
Christopher Smith