Bug 2623 - service summary/diagnostics
: service summary/diagnostics
Status: RESOLVED WONTFIX
: GRAM
wsrf discovery interface
: development
: Macintosh All
: P3 enhancement
: 4.4
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2005-01-25 15:45 by
Modified: 2012-09-05 11:42 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-01-25 15:45:01
GRAM should expose some Resource Properites that could be used for general
service diagnostics and 
summary information.

For example, the # of successful jobs, # of failed jobs since the container
started.  Maybe a moving 
average of the submission rate.  These would MJFR RPs.  A running total of
these could be maintained 
in the MJFS.

RFT is a good example on publishing useful information:
http://mds.globus.org:8080/webmds/webmds?info=indexinfo&xsl=servicegroupxsl

Something to considered is the benefits of changing GRAM to store it's resource
information in a DB 
instead of files on disk.  This would enable a more open ended query interface
to the job information.  
Like quering for the job states for all of a users jobs.
------- Comment #1 From 2005-01-25 15:54:30 -------
It is possibly a good idea that job-like services (GRAM, RFT) share a common
XML
schema for reporting this kind of information.
------- Comment #2 From 2005-01-25 16:02:02 -------
a)  
It seems to me that such RPs would fit in what the GLUE RPs are trying to achieve.   
So if we put dedicated RPs outside of the GLUE RPs, it could be good on the   
one hand because it would simpler to query, but bad on the other hand because   
it would make the resource/service interface less factored and more confusing.  
  
b)  
About the DB persistence thing:  
I don't see what persistence implementation has to do with query interface.   
Job persistence and job/factory service interfaces/query languages   
should be decoupled.   
Maybe you meant: Implementing persistence of jobs with an RDB as opposed to files   
may make performance of a complex query easier to implement?   
------- Comment #3 From 2005-01-27 09:16:37 -------
Good points Alain:

a) Yes. We should look at glue before inventing our own RPs.  One issue is scalability.  Glue has a way to 
list submitted jobs, but will that method work to query and get a response for 1000 jobs?

b) Yes.  I think you're right that they should be decoupled and that is what i meant. 
------- Comment #4 From 2007-09-19 11:37:50 -------
Reassigning to current GRAM developer to close/fix as appropriate.
------- Comment #5 From 2012-09-05 11:42:20 -------
Doing some bugzilla cleanup...  Resolving old GRAM3 and GRAM4 issues that are
no longer relevant since we've moved on to GRAM5.  Also, we're now tracking
issue in jira.  Any new issues should be added here:

http://jira.globus.org/secure/VersionBoard.jspa?selectedProjectId=10363