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

Keep user specific reason for offline slave when slave getting disconnected

    • Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Minor Minor
    • core
    • None
    • 2.481

      Jenkins 1.598

      1. When taking slave offline by user - you can specify a reason.
      If the slave is getting disconnected (i.e. after a reboot), the reason is changed to a java exception, and you can't see the original reason.

      2. When a slave is in a "connecting" state (slave agent being lunched) and is in offline state - the reason doesn't appear on the computer page (/computer/host...).

          [JENKINS-30101] Keep user specific reason for offline slave when slave getting disconnected

          1. Jenkins restart is one thing, after jenkins start it calls computers.updates (afair). So something can be related in this part of code.

          2. probably can be related to asynchronous actions between submitted runnable in threadPoolForRemoting (afair in this way it launches slaves) and offline marking/interruption.

          Kanstantsin Shautsou added a comment - 1. Jenkins restart is one thing, after jenkins start it calls computers.updates (afair). So something can be related in this part of code. 2. probably can be related to asynchronous actions between submitted runnable in threadPoolForRemoting (afair in this way it launches slaves) and offline marking/interruption.

          Tomer Galun added a comment -

          1. when I said reboot - I meant a reboot of the slave (Channel Termination)

          2. I guess you right.. Anyway, this is much less important

          Tomer Galun added a comment - 1. when I said reboot - I meant a reboot of the slave (Channel Termination) 2. I guess you right.. Anyway, this is much less important

          Tomer Galun added a comment - - edited

          hudson/slaves/SlaveComputer.java
          1. In the function setChannel there is the line(531):
          offlineCause = null;
          which remove the offline cause after the slave reconnect.
          I don't think this is the right behaviour we expect - The offline state should remain in case it made by User / CLI.

          2. line 473
          We might override a user offline cause with a ChannelTermination cause. I think the right way is, again, check if there is a user / CLI cause and if so - don't change it. although I'm not sure if I don't miss anything here... (what is the expected behaviour in case that the node is offline and it disconnect from the slave...)

          Tomer Galun added a comment - - edited hudson/slaves/SlaveComputer.java 1. In the function setChannel there is the line(531): offlineCause = null; which remove the offline cause after the slave reconnect. I don't think this is the right behaviour we expect - The offline state should remain in case it made by User / CLI. 2. line 473 We might override a user offline cause with a ChannelTermination cause. I think the right way is, again, check if there is a user / CLI cause and if so - don't change it. although I'm not sure if I don't miss anything here... (what is the expected behaviour in case that the node is offline and it disconnect from the slave...)

          I would make this as a bug rather than an improvement.  This makes Offline reasons provided by the user completely useless as a communication tool within the team regarding why this specific agent is offline.

          The Offline Reason is Effectively broken in the current behavior

          Eric Daigneault added a comment - I would make this as a bug rather than an improvement.  This makes Offline reasons provided by the user completely useless as a communication tool within the team regarding why this specific agent is offline. The Offline Reason is Effectively broken in the current behavior

            vlatombe Vincent Latombe
            galunto Tomer Galun
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: