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

Node.LabelMissing error in Jenkins 2.71

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Short problem description: Job on dedicated slave not started since Jenkins 2.71

       

      Detailed description:

      1. I have jobs that run only on slave nodes with dedicated labels (label-A && label-B).
      2. Then, I have slave nodes that contain these labels label-A, label-B, label-C, ... .
      3. In the slave node configuration, I have also configured that only a special user (user-ID coming from LDAP) is allowed to run jobs on this slave.
      4. Problem: when I want to launch the job, the job is queued with the hint Node.LabelMissing (I found it in Google: https://github.com/jenkinsci/jenkins/blob/master/core/src/main/resources/hudson/model/Messages_de.properties). When I move the mouse over the job in the queue, I get more details about the missing label. The list contains many many slave nodes which do not contain the label, which is correct. But it seems that my dedicated node is not considered at all.
      5. After rolling back to Jenkins 2.70 (exchanging the war file, no change in plugins), the job can be started without any problems.

        Attachments

          Activity

          Hide
          jglick Jesse Glick added a comment -

          In the slave node configuration, I have also configured that only a special user (user-ID coming from LDAP) is allowed to run jobs on this slave.

          Could you be more specific about how you have configured this? Some special plugin? Are there steps to reproduce this issue from scratch in a fresh installation (the Mock Agent and Mock Security Realm plugins are convenient for such cases)?

          Looking over changes in 2.71 I do not see anything obviously related to queue maintenance. There were some changes in User lookup which should not have had behavioral effects but it is possible, especially if some plugin is manipulating users in an unusual way.

          Show
          jglick Jesse Glick added a comment - In the slave node configuration, I have also configured that only a special user (user-ID coming from LDAP) is allowed to run jobs on this slave. Could you be more specific about how you have configured this? Some special plugin? Are there steps to reproduce this issue from scratch in a fresh installation (the Mock Agent and Mock Security Realm plugins are convenient for such cases)? Looking over changes in 2.71 I do not see anything obviously related to queue maintenance. There were some changes in User lookup which should not have had behavioral effects but it is possible, especially if some plugin is manipulating users in an unusual way.
          Hide
          michaelmotteler Michael M. added a comment -

          The slave node configuration was done like this:

          After changing the user-id to lowercase t12345 it works with Jenkins 2.73 now.

          So the problem was realted to some user-id stuff, thanks for the hint.

          Feel free to close this issue.

          Show
          michaelmotteler Michael M. added a comment - The slave node configuration was done like this: After changing the user-id to lowercase t12345 it works with Jenkins 2.73 now. So the problem was realted to some user-id stuff, thanks for the hint. Feel free to close this issue.
          Hide
          jglick Jesse Glick added a comment -

          Seems like a possible core regression affecting job-restrictions. I am not familiar with this code but Oleg Nenashev may be able to evaluate. From a quick look I think AbstractUserCauseRestriction is at fault for not taking into account the realm’s configured user & group IdStrategy. Not exactly sure how the 2.71 update would have changed that; perhaps the UserIdCause constructor is behaving differently w.r.t. stored vs. in-memory user IDs?

          Show
          jglick Jesse Glick added a comment - Seems like a possible core regression affecting job-restrictions . I am not familiar with this code but Oleg Nenashev may be able to evaluate. From a quick look I think AbstractUserCauseRestriction is at fault for not taking into account the realm’s configured user & group IdStrategy . Not exactly sure how the 2.71 update would have changed that; perhaps the UserIdCause constructor is behaving differently w.r.t. stored vs. in-memory user IDs?
          Hide
          oleg_nenashev Oleg Nenashev added a comment -

          I need to check it, but it looks bad

          Show
          oleg_nenashev Oleg Nenashev added a comment - I need to check it, but it looks bad
          Hide
          svscorp Ilia Shakitko added a comment -

          Jesse Glick was it starting before? I have Jenkins 2.60.3.1 and if I restrict a node with label "restrict" usage to a user id "test", job pipeline with code:

          node('restrict') {
            sleep 10
            echo 'Hello World'
          }
          

          just hangs/stays in build queue (both users "test" and "admin")

          Started by user admin
          [Pipeline] node
          Still waiting to schedule task
          ; Jenkins doesn’t have label restrict
          

          If I uncheck restriction it works obviously.

          Not sure is it the same issue or a separate one? Oleg Nenashev

          Show
          svscorp Ilia Shakitko added a comment - Jesse Glick was it starting before? I have Jenkins 2.60.3.1  and if I restrict a node with label "restrict" usage to a user id "test", job pipeline with code: node( 'restrict' ) { sleep 10 echo 'Hello World' } just hangs/stays in build queue (both users "test" and "admin") Started by user admin [Pipeline] node Still waiting to schedule task ; Jenkins doesn’t have label restrict If I uncheck restriction it works obviously. Not sure is it the same issue or a separate one? Oleg Nenashev
          Hide
          oleg_nenashev Oleg Nenashev added a comment -

          Maybe it's the same one. I will try to take a look after Jenkins World

          Show
          oleg_nenashev Oleg Nenashev added a comment - Maybe it's the same one. I will try to take a look after Jenkins World
          Hide
          svscorp Ilia Shakitko added a comment -

          Oleg Nenashev I am also in Jenkins World. Let's connect  We can have a look together.

          Show
          svscorp Ilia Shakitko added a comment - Oleg Nenashev I am also in Jenkins World. Let's connect  We can have a look together.

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            michaelmotteler Michael M.
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Dates

              Created:
              Updated: