[torqueusers] inter-torque/pbs-server protocol compatibility

Dave Jackson jacksond at clusterresources.com
Mon Jan 16 10:16:12 MST 2006


David,

  We are working hard to maintain as much compatibility as possible.
However, a few incompatibilities have been introduced when there was no
other proper way to improve TORQUE reliability, scalability, or
usability.

  To date, there still should be server<->server and server<->scheduler
backwards compatibility back to OpenPBS.  However, a number of protocol
changes have made server<->mom communication incompatible with pre
TORQUE 2.0 release.

  Going forward, we are attempting to maintain the following:

full compatibility of server<->server and server<->scheduler releases
within releases (ie all 2.1.x releases will inter-operate).  

full compatibility of server<->mom components within a release (ie, all
patch levels of 2.1.1 will inter-operate)

  Clearly we will attempt to maintain backwards compatibility where-ever
possible and where incompatibilites are introduced, they will called out
in the CHANGELOG and in announcements.  If additional steps on our side
are desired, please let us know.

Thanks,
Dave


On Mon, 2006-01-16 at 13:56 +0000, David Golden wrote:
> Given earlier:
> http://www.supercluster.org/pipermail/torqueusers/2006-January/002947.html
> 
> raising vaguely related question:
> 
> Is there commitment to network protocol compatibility
> between  different patchlevels,minor versions,major versions
> of torque for
> mom<->server 
> server<->server  (routing queues!)
> server<->sheduler
> 
> I can see why people devving the relatively rapidly developing torque 
> tree might like to keep protocol extension options open for various 
> improvements, just wondering to what extent we should keep clusters 
> torque versions synchronised if we're using routing queues between 
> them is all.  Obviously, it's probably a good idea to have most software
> on clusters you're routing between matched fairly closely _anyway_,
> but I'm wondering how much leeway there is.
> 
> (presently we've got a couple with different minor version
> numbers, and they seem to work okay, but that could be blind 
> luck. Has ramifications for the strategy we use for grid-enabling
> our clusters...)
> 
> 
> _______________________________________________
> torqueusers mailing list
> torqueusers at supercluster.org
> http://www.supercluster.org/mailman/listinfo/torqueusers



More information about the torqueusers mailing list