Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-63607

Improve the version column checks for remoting compatibility

      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.

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

          Mark Waite added a 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

          Mark Waite added a 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

          Amit Dar added a 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?

          Amit Dar added a 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?

          Mark Waite added a 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.

          Mark Waite added a 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.

          Amit Dar added a comment - - edited

          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

          Amit Dar added a comment - - edited 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

          Valentin Delaye added a comment - - edited

          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

          Valentin Delaye added a comment - - edited 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

          I've submited a draft PR : https://github.com/jenkinsci/versioncolumn-plugin/pull/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

          Valentin Delaye added a comment - I've submited a draft PR : https://github.com/jenkinsci/versioncolumn-plugin/pull/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

            Unassigned Unassigned
            amidar Amit Dar
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: