[JENKINS-63607] Improve the version column checks for remoting compatibility

[jenkins-infra-bot]

we are using a lot of agents with swarm plugin.

all agents always download the agent, and then connect to the server.

installing versions node monitor 2.1 caused all the nodes to go OFFLINE since the version node plugin reports remoting 4.5 ON CLIENT SIDE as too old...

 

simply put - when a node reports it has remoting version 4.5 and the master has remoting version 4.3 -> the node is taken offline.

---

Originally reported by amidar, imported from: Improve the version column checks for remoting compatibility

• status: Open
• priority: Minor
• component(s): versioncolumn-plugin
• label(s): newbie-friendly
• resolution: Unresolved
• votes: 0
• watchers: 3
• imported: 20251210-221934

Raw content of original issue

we are using a lot of agents with swarm plugin.

all agents always download the agent, and then connect to the server.

installing versions node monitor 2.1 caused all the nodes to go OFFLINE since the version node plugin reports remoting 4.5 ON CLIENT SIDE as too old...

 

simply put - when a node reports it has remoting version 4.5 and the master has remoting version 4.3 -> the node is taken offline.

environment

jenkins 2.235.5<br/>
versioncolumn plugin 2.1

4 attachments

• node_monitoring.PNG

  

• old_agent.PNG

  

• remoting_mismatch.PNG

  

• screencapture-mark-pc2-markwaite-net-8080-computer-configure-2020-09-11-21_12_42-edit.png

  

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  The versioncolumn plugin can be configured to not mark the agent offline when the remoting version does not match the version on the Jenkins controller.
  
    
  
  See JENKINS-63557 that announces the release of swarm client 3.23 (for Jenkins 2.249.1).  You may need to remain with swarm plugin 3.22 on Jenkins 2.235.x
  

The versioncolumn plugin can be configured to not mark the agent offline when the remoting version does not match the version on the Jenkins controller.

See JENKINS-63557">JENKINS-63557 that announces the release of swarm client 3.23 (for Jenkins 2.249.1). You may need to remain with swarm plugin 3.22 on Jenkins 2.235.x

[jenkins-infra-bot]

amidar:

• Original comment link
• Raw content of original comment:

  Hi markewaite,
  
   
  
  thanks for the quick response!
  
  I just want to make sure I fully understand - you are suggesting a "workaround" rather than a solution.
  
  what I'm trying to say is that the remoting version should "behave" like the java version. it should offer at least some sort of validation mechanism and not provide a simple "check/don't check" mechanism for the specific remoting version.
  
   
  
  shouldn't an agent with remoting version 4.5 be able to connect to a master with remoting version 4.3? I don't see a reason why it shouldn't (unless there are some breaking api changes, which means the agent should be versioned 5.something....
  
   
  
  don't you agree?
  

Hi markewaite,

 

thanks for the quick response!

I just want to make sure I fully understand - you are suggesting a "workaround" rather than a solution.

what I'm trying to say is that the remoting version should "behave" like the java version. it should offer at least some sort of validation mechanism and not provide a simple "check/don't check" mechanism for the specific remoting version.

 

shouldn't an agent with remoting version 4.5 be able to connect to a master with remoting version 4.3? I don't see a reason why it shouldn't (unless there are some breaking api changes, which means the agent should be versioned 5.something....

 

don't you agree?

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  Yes, I'm suggesting a work around.  I agree that an agent running a newer version of remoting should be able to connect to an older remoting version on the Jenkins controller.  I suspect that is an uncommon scenario, since most of the time the controller is upgraded before the agents are upgraded.
  

Yes, I'm suggesting a work around. I agree that an agent running a newer version of remoting should be able to connect to an older remoting version on the Jenkins controller. I suspect that is an uncommon scenario, since most of the time the controller is upgraded before the agents are upgraded.

[jenkins-infra-bot]

amidar:

• Original comment link
• Raw content of original comment:

  I don't understand why the jenkins controller should/would be upgraded before the agent. we are upgrading the plugins all the time to keep all the system up to date as much as possible.
  
  since we are using swarm plugin massively, we keep it always up to date with the latest compatible version to the controller.
  
  the last upgrade was a disaster to us since all the agent went offline immediately after the update...
  
  anyway - thanks for the solution 
  

I don't understand why the jenkins controller should/would be upgraded before the agent. we are upgrading the plugins all the time to keep all the system up to date as much as possible.

since we are using swarm plugin massively, we keep it always up to date with the latest compatible version to the controller.

the last upgrade was a disaster to us since all the agent went offline immediately after the update...

anyway - thanks for the solution

[jenkins-infra-bot]

jonesbusy:

• Original comment link
• Raw content of original comment:

  Hi,
  
  I would like to also have a checkbox for not disconnecting the agent if the remoting doesn't match. The same as the JVM version.
  
  
  
   
  
  We have hundreds of controller, thousand of agents sometimes maintained by external teams and having the node offline is not a solution.
  
  As a Jenkins admin I would like to have only the monitor to alert me of instances with potential issues but not disconnect agent.
  
  For the moment the checkbox 'Disconnect agent when incompatibility is found' only work for JVM version. Not remoting.
  
   
   
  I volunteer to submit a PR to add a checkbox also for the remoting monitor
  
  Thanks
  

Hi,

I would like to also have a checkbox for not disconnecting the agent if the remoting doesn't match. The same as the JVM version.

We have hundreds of controller, thousand of agents sometimes maintained by external teams and having the node offline is not a solution.

As a Jenkins admin I would like to have only the monitor to alert me of instances with potential issues but not disconnect agent.

For the moment the checkbox 'Disconnect agent when incompatibility is found' only work for JVM version. Not remoting.

 
I volunteer to submit a PR to add a checkbox also for the remoting monitor

Thanks

[jenkins-infra-bot]

jonesbusy:

• Original comment link
• Raw content of original comment:

  I've submited a draft PR : JENKINS-63607 Do not disconnect agent when remoting doesn't match #192 that include the option to not disconnect the agent
  
  Core will by default reject older agent : https://github.com/jenkinsci/jenkins/blob/551043065bc672102fb8b07e8008f959ebc566fa/core/src/main/java/hudson/slaves/SlaveComputer.java#L666C8-L666C8
  
  So unchecking this box will allow newer agent to connect
  
  I agree that sometimes is not possible to upgrade all controller and agent at the same time to have remoting matching, specially in very large infrastructure
  

I've submited a draft PR : #192 that include the option to not disconnect the agent

Core will by default reject older agent : https://github.com/jenkinsci/jenkins/blob/551043065bc672102fb8b07e8008f959ebc566fa/core/src/main/java/hudson/slaves/SlaveComputer.java#L666C8-L666C8

So unchecking this box will allow newer agent to connect

I agree that sometimes is not possible to upgrade all controller and agent at the same time to have remoting matching, specially in very large infrastructure

[jenkins-infra-bot]

[Original relates_to from Jira: JENKINS-72688]

[jenkins-infra-bot]

[Original relates_to from Jira: JENKINS-70298]