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

[Peter G Lane]

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.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3720 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/ogsa-bes-wg/attachments/20060524/88b3451d/attachment.bin