Bug 720 - allow gram client to detect the version of a gram server
: allow gram client to detect the version of a gram server
Status: RESOLVED FIXED
: GRAM
gt2 Gatekeeper/Jobmanager
: unspecified
: PC All
: P2 enhancement
: ---
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2003-02-17 17:09 by
Modified: 2011-12-19 10:18 (History)


Attachments


Note

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


Description From 2003-02-17 17:09:17
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
------- Comment #1 From 2003-02-17 18:05:01 -------
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.

------- Comment #2 From 2003-02-18 14:25:03 -------
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
------- Comment #3 From 2011-12-19 10:18:58 -------
A version check was added in 5.0