This RFE of mine from last year relates to the same issue, in a
different service:

  http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=299

-Peter

On Mon, Feb 17, 2003 at 05:09:20PM -0600, bugzilla-daemon@mcs.anl.gov wrote:
> http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=720
> 
>            Summary: allow gram client to detect the version of a gram server
>            Product: GRAM
>            Version: unspecified
>           Platform: PC
>         OS/Version: All
>             Status: NEW
>           Severity: enhancement
>           Priority: P2
>          Component: Gatekeeper/Jobmanager
>         AssignedTo: smartin@mcs.anl.gov
>         ReportedBy: tannenba@cs.wisc.edu
>                 CC: adesmet@cs.wisc.edu,bester@mcs.anl.gov,jfrey@cs.wisc.edu
>                     ,jms@mcs.anl.gov,pfc@cs.wisc.edu,roy@cs.wisc.edu,welch@m
>                     cs.anl.gov
> 
> 
> With all of the subtle semantic differences between GRAM versions and 
> jobmanager implementations/versions, it is getting very difficult for a client 
> to make sense of it all.   Y'all know what I'm talking about: some old versions 
> of GRAM do not support restart, some do; some versions of GRAM have file 
> staging states, some don't; some versions of GRAM try to remove jobs from the 
> local scheduler on state FAILED, some don't; some versions of GRAM don't remove 
> the state file after a commit timeout, some do.
> 
> And no grid of any size ever seems to upgrade all gatekeepers at the same 
> time.  Thus, GRAM clients need to figure out the capabilities and 
> implementation versions of the gram servers they are communicating with.
> 
> Is there a way to do this that I am not aware of?  If not, it is *high time* 
> that this be added into GRAM.  It is getting really crazy all the hoops that 
> Condor-G jumps through just to figure out what capabilities the remote 
> jobmanager understands, and it is also becoming very inefficient...
> 
> Any thoughts here?
> 
> Thanks!
> Todd
> UW Condor Team
> 
> 
> 
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.

Todd,

I don't think there is a way to get the version information from a job 
manager.  I agree it should be possible.  One possibility would be for the JM 
to reply with the version from the job manager's package metadata (e.g. 3.2). 
Another would be to integrate DiRT info (CVS commit timstamp and branch info) 
more details at http://www-unix.mcs.anl.gov/~link/dirt.txt.  This is available 
to all Globus source, just not integreated throughout.

I think what we want could be accomplished by either method.  One method would 
say is the timstamp < X  the other would say is the version < X.

Seems like the MDS could be of help here as well, but I think you want to be 
able to query the service directly for version information - right?

What about the perl JM scheduler script that is installed, do you need that 
version information as well?

-Stu

A version check was added in 5.0