On Wed, 2006-05-24 at 12:21 +0200, Moreno Marzolla wrote:
Peter G Lane wrote:
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.
Ok. I personally can't come up with a use case, but that doesn't mean one doesn't exist. Care to elaborate why this is useful? Do you not trust that the service will do what you tell it to do?
Probably it is not a very frequent use case; anyway, if users are allowed to authorize other users to issue commands (i.e., suspend, resume, cancel operations) on their own jobs, then it may be useful to inspect the list of commands which have been issued to a given job, as they may have not been given by the job owner. This feature may be useful for tracking down problems (for debugging purposes).
Perhaps, rather than making such "job command list" property mandatory, we may use the "Extensibility" element which is cited in the ESI document on section 5.1?
Yeah, perhaps that's a better idea. Auditing seems to me a very different problem than the one that BES is trying to solve. GRAM, for example, is implementing auditing that logs straight to a database. I think we'd want the flexibility to do this our own way. Peter
Moreno.