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

Renaming jenkins agents persists previously named agent on restart

    XMLWordPrintable

Details

    • 2.174

    Description

      Renaming an agent does not persist across restarts, and jenkins loads back the old agent as well as the new agent. The root issue seems to be that the directory under ${JENKINS_HOME}/nodes/<agent> is left untouched on a rename, and is left alongside the one created for the new agent. 

      Steps to reproduce:

      1. Create a new agent
      2. Configure -> Rename the agent and click Save
      3. Restart Jenkins to see the old agent appear

      This caused several issues where the old and new agents were trying to connect to the same host, causing build issues

      This is reproducible on several jenkins LTS versions (2.107, 2.138, 2.150), so I'm not sure when it was introduced. 

      Attachments

        Issue Links

          is caused by

          Improvement - An improvement or enhancement to an existing feature or task. JENKINS-33780 Listener for slave creation/deletion/update.

          • Major - Major loss of function.
          • Resolved
          relates to

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-27565 Nodes can be removed as idle before the assigned tasks have started

          • Major - Major loss of function.
          • Closed
          links to

          Web Link PR 3925

          Activity

            Ascending order - Click to sort in descending order
            adangi Anish Dangi added a comment -

            oleg_nenashev jglick

            adangi Anish Dangi added a comment - oleg_nenashev jglick
            jglick Jesse Glick added a comment -

            If it is a regression my casual guess would be that it was introduced with Nodes by stephenconnolly in JENKINS-27565. Either way, it ought to be easy enough to fix given a functional test with RestartableJenkinsRule. I suspect Nodes.replaceNode needs to do a directory rename when the old and new names differ.

            jglick Jesse Glick added a comment - If it is a regression my casual guess would be that it was introduced with Nodes by stephenconnolly in JENKINS-27565 . Either way, it ought to be easy enough to fix given a functional test with RestartableJenkinsRule . I suspect Nodes.replaceNode needs to do a directory rename when the old and new names differ.
            adangi Anish Dangi added a comment -

            jglick This was caused by JENKINS-33780 . It replaced the prior method which performed a config save after updating the list of nodes, with the replaceNode method, which didn't do so. I opened a PR to address this. https://github.com/jenkinsci/jenkins/pull/3925

            adangi Anish Dangi added a comment - jglick This was caused by  JENKINS-33780  . It replaced the prior method which performed a config save after updating the list of nodes, with the replaceNode  method, which didn't do so. I opened a PR to address this.  https://github.com/jenkinsci/jenkins/pull/3925
            batmat Baptiste Mathus added a comment -

            Thanks adangi this was merged earlier today, and should land in next weekly release. Likely 2.174

            batmat Baptiste Mathus added a comment - Thanks adangi this was merged earlier today, and should land in next weekly release. Likely 2.174
            adangi Anish Dangi added a comment -

            batmat Thanks. This seems like a safe candidate for backporting to older LTS releases. Would you consider that?

            adangi Anish Dangi added a comment - batmat Thanks. This seems like a safe candidate for backporting to older LTS releases. Would you consider that?
            batmat Baptiste Mathus added a comment -

            adangi I proposed it for upcoming 2.164.3, but it has been rejected. See https://groups.google.com/d/msgid/jenkinsci-dev/845a8da6-c20e-1f50-e69e-319fe283b1f7%40gmail.com for the discussion.

            Given the new selected baseline for lts is higher than 2.174, no backport will be needed.

            Thanks

            batmat Baptiste Mathus added a comment - adangi I proposed it for upcoming 2.164.3, but it has been rejected. See https://groups.google.com/d/msgid/jenkinsci-dev/845a8da6-c20e-1f50-e69e-319fe283b1f7%40gmail.com for the discussion. Given the new selected baseline for lts is higher than 2.174, no backport will be needed. Thanks
            adangi Anish Dangi added a comment -

            batmat I don't see this mentioned in the jenkins 2.176 LTS changelog at https://jenkins.io/changelog-stable/. Is this actually included?

            adangi Anish Dangi added a comment - batmat I don't see this mentioned in the jenkins 2.176 LTS changelog at https://jenkins.io/changelog-stable/ . Is this actually included?

            People

              adangi Anish Dangi
              adangi Anish Dangi
              Votes:
              2 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: